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Vorwort 


VHDL! ist ein weltweit akzeptierter Standard zur Dokumentation, 
funktionalen Simulation und zum Datenaustausch beim Entwurf digi- 
taler Systeme. VHDL hat in den letzten Jahren ausgehend von den 
USA seinen weltweiten Siegeszug angetreten. Mittlerweile findet die 
Sprache in vielen Entwicklungsabteilungen Verwendung; kaum ein 
Unternehmen wird sich dem Einsatz von VHDL beim Entwurf digi- 
taler Hardware entziehen können. 


Das Einsatzgebiet von VHDL wurde im Laufe der Zeit in Richtung 
Synthese erweitert. Damit wurden neue, produktivere Wege in der 
Elektronikentwicklung eröffnet. Die aktuellen Bestrebungen inter- 
nationaler Gremien gehen in Richtung analoger Erweiterung des Stan- 
dards, was den technologischen Fortschritten und der Entwicklung hin 
zu gemischt analog-digitalen Systemen bzw. Mikrosystemen dienlich 
sein wird. 


Die Probleme, die beim Einsatz von VHDL auftreten, dürfen jedoch 
nicht verschwiegen werden. Es handelt sich um eine sehr mächtige 
Sprache, die erst nach längerem praktischen Einsatz richtig beherrscht 
wird. Der Einstieg ist insbesondere für diejenigen Hardwareentwickler 
schwierig, die noch nicht intensiv mit einer Programmiersprache ge- 
arbeitet haben. Die psychologische Barriere darf dabei nicht unter- 
schätzt werden. Hinzu kommt, daß es mit der Einführung der "Spra- 
che" VHDL allein nicht getan ist: Die darauf basierende Entwurfs- 
methodik erfordert eine neue Arbeitsweise, ein Überdenken gewohnter 
Schemata und nicht zuletzt die Verwendung neuer Werkzeuge. 


1 VHDL = VHSIC (Very High Speed Integrated Circuit) 
Hardware Description Language 
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Vorwort 


Die anfänglichen technischen Probleme (fehlende Herstellerbiblio- 
theken, relativ langsame Simulation auf Gatterebene, kein automati- 
siertes "Backannotation"!) sind schon weitgehend beseitigt. Eine grös- 
sere Herausforderung stellt allerdings die Tatsache dar, daß der durch 
verschiedene Syntheseprogramme unterstützte VHDL-Sprachumfang 
eingeschränkt und nicht identisch ist. 


Ein gravierendes Problem ist auch die starke Abhängigkeit des Syn- 
theseergebnisses von der Qualität der VHDL-Beschreibung, mit dem 
Schlagwort "what you write is what you get" treffend beschrieben. 


In den letzten Jahren wurde versucht, durch Einführung sog. "Front- 
End-Tools" den Entwickler vom Erlernen und vollen Verständnis der 
Sprache zu entlasten. Diese Werkzeuge erzeugen aus einer graphisch 
definierten Verhaltensbeschreibung per Knopfdruck VHDL-Code, der 
oft als "synthesegerecht" bezeichnet wird. Dadurch gestaltet sich der 
Entwurfsablauf für viele Anwendungsfälle produktiver, denn ein Auto- 
matengraph oder ein Statechart ist nun einmal anschaulicher und 
leichter zu übersehen als seitenlange IF... THEN...ELSE- und CASE- 
Anweisungen. 


Die oben genannten Abhängigkeiten des Syntheseergebnisses vom 
VHDL-Code stellen hohe Ansprüche an diese Werkzeuge. Da Front- 
End- und Synthesetools in der Regel jedoch von verschiedenen Her- 
stellern angeboten werden, ist der erzeugte VHDL-Code für die an- 
schließende Synthese oft wenig optimiert bzw. teilweise sogar unge- 
eignet. Die Abhängigkeiten sind dabei so komplex, daß die erforder- 
lichen manuellen Änderungen am Quellcode nur von Experten be- 
herrscht werden. Vor einem blinden Vertrauen auf das Ergebnis dieser 
Werkzeugkette soll deshalb gewarnt werden: VHDL nur als Daten- 
austauschformat ohne Verständnis der Syntax und Semantik einge- 
setzt, kann leicht zu unbefriedigenden oder gar schlechten Ergebnis- 
sen führen. Deshalb sind Bücher, die das notwendige Hintergrundwis- 
sen zur Syntax und zur Interpretation der Sprache VHDL liefern, auch 
beim Einsatz modernster Entwicklungswerkzeuge unverzichtbar. 


1 Backannotation = Nachträgliche Berücksichtigung layoutabhängiger 
Verzögerungszeiten 
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Vorwort 


In dem vorliegenden Buch ist es den Autoren gelungen, erstmals eine 
umfassende deutschsprachige Einführung in Syntax und Semantik der 
Sprache VHDL sowie deren Anwendung für Simulation und Synthese 
zu geben und anhand von einfachen Beispielen zu erläutern. Damit 
wird zur Verbreitung von VHDL im deutschsprachigen Raum ein 
wichtiger Beitrag erbracht. 


Karlsruhe, im März 1994 
Prof. Dr.-Ing. K. D. Müller-Glaser 
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Zu diesem Buch 


Als eine der wenigen deutschsprachigen Veröffentlichungen über 
VHDL soll das vorliegende Werk eine breite Leserschicht ansprechen: 
Entscheidungsträger finden hier Informationen über Aufgaben von 
VHDL, die Designmethodik und Anwendungsmöglichkeiten der 
Hardwarebeschreibungssprache. Anwender werden vor allem durch 
den VHDL-Syntaxteil angesprochen, der sowohl für Anfänger als 
auch für Experten interessante Hinweise, Tips und Tricks und Nach- 
schlagemöglichkeiten bietet. Für diese Gruppe von Lesern sind auch 
die Kapitel über die Anwendung von VHDL gedacht. 


Das Buch gliedert sich in vier Teile: 


Teil A legt als Einführung die geschichtliche Entwicklung sowie die 
Aufgabengebiete von VHDL dar. Ebenso wird der Einsatz von VHDL 
im strukturierten Elektronikentwurf und der grundsätzliche Aufbau 
von VHDL-Modellen erläutert. 


Der zweite Teil (Teil B) bildet den Schwerpunkt des vorliegenden Wer- 
kes und enthält die Beschreibung der VHDL-Syntax. Hier werden alle 
Konstrukte der zur Zeit von Entwicklungswerkzeugen unterstützten 
Sprachnorm ("VHDL’87") vorgestellt. Daneben wird auf alle Verände- 
rungen eingegangen, welche die überarbeitete Norm "VHDL’93" mit 
sich bringt. 


In Teil C schließlich findet die praktische Anwendung von VHDL, mit 
den Schwerpunkten Simulation und Synthese, ihren Platz. Es werden 
zahlreiche Hinweise zur Erstellung von VHDL-Modellen gegeben. 


Im letzten Abschnitt des Buches, dem Anhang (Teil D), finden sich ne- 
ben einer Literaturliste auch Hinweise zu VHDL-Gremien und Arbeits- 
gruppen. Mehrere Übungsaufgaben ermöglichen die Vertiefung der 
erworbenen Kenntnisse. Die Musterlösungen dazu können der dem 
Buch beiliegenden Diskette entnommen werden. 
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Zu diesem Buch 


Dieses Buch basiert auf den Kenntnissen und Erfahrungen, die wir 
während unserer Tätigkeit am Lehrstuhl für Rechnergestützten Schal- 
tungsentwurf der Universität Erlangen-Nürnberg und am Institut für 
Technik der Informationsverarbeitung der Universität Karlsruhe er- 
worben haben. Im Vordergrund standen hier die Betreuung zahl- 
reicher VHDL-Sprachkurse für Industriekunden und die Vermittlung 
des Themas VHDL an Studenten in Erlangen und Karlsruhe. 


Wir danken Herrn Prof. Dr.-Ing. K. D. Müller-Glaser (Institut für 
Technik der Informationsverarbeitung) und Herrn Dr.-Ing. H. Rauch 
(Lehrstuhl für Rechnergestützten Schaltungsentwurf) für ihr weitrei- 
chendes Interesse und die Unterstützung, welche die Entstehung dieses 
Buches erst ermöglicht haben. 


Außerdem möchten wir uns bei Herrn G. Wahl, dem Programmleiter 
für Elektronikbücher des Franzis-Verlages, für die vielfältigen Anre- 
gungen und die Bereitschaft, das neue Thema "VHDL" aufzugreifen, 
bedanken. 


Wir möchten weiterhin darauf hinweisen, daß das Titelbild lediglich 
symbolischen Charakter hat. Die unterschiedlichen Namen im Entity- 
Rahmen des abgedruckten VHDL-Modells haben sich leider beim 
Übertragen in die Druckvorlage eingeschlichen. 


Karlsruhe und Erlangen, im März 1994 
Gunther Lehmann, Bernhard Wunder, Manfred Selz 
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Teil A Einführung 
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1 Entwurf elektronischer 
Systeme 


1.1 Motivation 


Die heutige Situation beim Entwurf elektronischer Systeme ist durch 
folgende Aspekte gekennzeichnet: 


m Komplexität und Integrationsdichte nehmen ständig zu. Haupt- 
gesichtspunkte dabei sind: 


O höhere Packungsdichten aufgrund geringerer Struktur- 
größen beschleunigen das Vordringen von Produkten mit 
komplexem, elektronischem "Innenleben", 


O die Anforderungen an die Leistungsfähigkeit (Performan- 
ce) der Elektronik (geringer Platzbedarf, hohe Taktrate, 
geringer Leistungsverbrauch, hohe Zuverlässigkeit) stei- 
gen. 


71 Wachsender Konkurrenzdruck und Anforderungen der Kunden 
bedingen immer kürzere Entwicklungszeiten. Eine Verzögerung 
der Markteinführung eines Produktes kann den Umsatz dra- 
stisch verringern und damit den Erfolg eines Unternehmens ge- 
fährden ("time to market"-Problematik). 


m Die Komplexität, eine Wiederverwendung von Entwurfsdaten 
und die Wartung des fertigen Produktes erfordern eine vollstän- 
dige, widerspruchsfreie und verständliche Dokumentation. 


1.2 Entwurfssichten 


Die Entwicklung elektronischer Systeme ist bei der heutigen Kom- 
plexität und den genannten Anforderungen nur durch eine struktu- 
rierte Vorgehensweise beherrschbar. Idealerweise wird man, ausgehend 
von einer Spezifikation auf Systemebene, die Schaltungsfunktion par- 
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1 Entwurf elektronischer Systeme 


titionieren ("Funktionale Dekomposition") und die grundsätzlichen 
Funktionen den einzelnen Modulen zuordnen. Schrittweise wird der 
Entwurf weiter strukturiert und zunehmend mit Details der Imple- 
mentierung versehen, bis die für die Fertigung des elektronischen 
Systems notwendigen Daten vorliegen. Dies können Programmier- 
daten für Logikbausteine, Layouts für Leiterplatten oder Maskenbän- 
der für die IC-Fertigung sein. 


Man unterscheidet beim Entwurf elektronischer Systeme üblicherweise 
die drei Sichtweisen Verhalten, Struktur und Geometrie. Diese Ein- 
teilung wird durch das sog. Y-Diagramm verdeutlicht (Abb. A-1): 


Systemebene 


Verhalten Algorithmische Ebene Struktur 
Register- 
Transfer-Ebene 


CHCPUs, Speicher 


Module, Leitungen 
Gailter, Flip-Flaps, Leitungen 


Geometrie 


Abb. A-1: Y-Diagramm nach Gajski-Walker [WAL 85] 


Gleichzeitig zu den drei Sichtweisen, die durch die Äste im Y-Dia- 
gramm repräsentiert werden, sind auch die verschiedenen Abstrak- 
tionsebenen durch Kreise mit unterschiedlichen Radien dargestellt. Ein 
großer Radius bedeutet hohe Abstraktion. Man kann nun vereinfacht 
den Entwurf elektronischer Systeme als eine Reihe von Transformatio- 
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A Einführung 


nen (Wechsel der Sichtweise auf einem Abstraktionskreis) und Ver- 
feinerungen (Wechsel der Abstraktionsebene innerhalb einer Sicht- 
weise) im Y-Diagramm darstellen. Beginnend auf dem Verhaltensast in 
der Systemebene wird der Entwurf durch Verfeinerungs- und Syn- 
theseschritte bis hin zum Layout auf dem geometrischen Ast durchge- 
führt. Ein "Place- and Route"-Werkzeug für Standardzellenentwürfe 
überführt beispielsweise eine strukturale Beschreibung in der Logik- 
ebene (Gatternetzliste) in eine geometrische Beschreibung in der 
Schaltkreisebene (IC-Layout). 


Das reine Top-Down-Vorgehen (Entwicklung in Richtung Kreismittel- 
punkt) kann dabei nicht immer konsequent beibehalten werden. 
Verifikationsschritte zwischen den einzelnen Ebenen zeigen Fehler 
beim Entwurf auf. Gegebenenfalls muß man das jeweilige Entwurfs- 
ergebnis modifizieren, den Entwurfsschritt wiederholen oder sogar auf 
höherer Abstraktionsebene neu einsetzen. Man spricht deshalb auch 
vom "Jojo-Design". 


1:3 Entwurfsebenen 
1.3.1 Systemebene 


Die Systemebene beschreibt die grundlegenden Charakteristika eines 
elektronischen Systems. In der Beschreibung werden typische Blöcke, 
wie Speicher, Prozessoren und Interface-Einheiten verwendet. Diese 
Module werden durch ihre Funktionalität (im Falle eines Prozessors 
z.B. durch dessen Befehlssatz), durch Protokolle oder durch stochasti- 
sche Prozesse charakterisiert. Auf dieser Ebene dominieren meist noch 
die natürliche Sprache und Skizzen als Beschreibungsmittel. 


Es werden auf Systemebene noch keinerlei Aussagen über Signale, 
Zeitverhalten und detailliertes funktionales Verhalten der einzelnen 
Blöcke getroffen. Vielmehr dient sie der Partitionierung der gesamten 
Schaltungsfunktion. In der geometrischen Sicht erfolgt auf dieser 
Ebene beispielsweise eine erste Unterteilung der Chipfläche. 
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1 Entwurf elektronischer Systeme 
1.3.2 Algorithmische Ebene 


Auf dieser Ebene wird ein System oder eine Schaltung durch neben- 
läufige (d.h. parallel ablaufende) Algorithmen beschrieben. Typische 
Beschreibungselemente dieser Ebene sind Funktionen, Prozeduren, 
Prozesse und Kontrollstrukturen. Auf der Algorithmischen Ebene wird 
ein elektronisches System in der strukturalen Sicht durch allgemeine 
Blöcke beschrieben, die über Signale miteinander Kommunizieren. In 
der Verhaltenssicht dagegen wird die Beschreibung des Verhaltens 
durch eine algorithmische Darstellung mit Variablen und Operatoren 
vorgenommen. 


Es wird kein Bezug zur späteren Struktur der Realisierung (Hardware- 
partitionierung) gegeben. Desgleichen werden auch keine zeitlichen 
Details durch Takt- oder Rücksetzsignale eingeführt. 


1.3.3 Register-Transfer-Ebene 


Bei Beschreibungen auf der Register-Transfer-Ebene ("Register Trans- 
fer Level", RTL) werden die Eigenschaften einer Schaltung durch 
Operationen (z.B. Addition) und durch den Transfer der verarbeiteten 
Daten zwischen Registern spezifiziert. Typischerweise werden in die 
Beschreibung Takt- und Rücksetzsignale integriert. Die einzelnen 
Operationen sind dann den Werten oder Flanken dieser Signale zuge- 
ordnet, so daß die zeitlichen Eigenschaften schon relativ genau defi- 
niert werden können. 


In der strukturalen Sicht werden Elemente wie Register, Codierer, Mul- 
tiplexer oder Addierer durch Signale miteinander verknüpft. In der 
Verhaltenssicht findet man vorwiegend Beschreibungen in Form von 
endlichen Automaten vor. Die Grobeinteilung der Chipfläche wird in 
der geometrischen Sicht zu einem sog. Floorplan verfeinert. 


Eine mehr oder weniger automatisierte Umsetzung der Verhaltens- 
beschreibung in eine strukturale Beschreibung auf der Logikebene 
wird inzwischen durch kommerzielle Werkzeuge angeboten (d.h. Be- 
schreibungen auf RT-Ebene sind meist synthetisierbar). 
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A Einführung 
1.3.4 Logikebene 


Auf der Logikebene werden die Eigenschaften eines elektronischen 
Systems durch logische Verknüpfungen und deren zeitliche Eigen- 
schaften (i.a. Verzögerungszeiten) beschrieben. Der Verlauf der Aus- 
gangssignale ergibt sich dabei durch die Anwendung dieser Verknüp- 
fungen auf die Eingangssignale. Die Signalverläufe sind wertdiskret, 
d.h. die Signale nehmen nur bestimmte, vordefinierte Logikwerte (z.B. 
low‘, 'high‘, “undefined‘) an. 

In der strukturalen Sichtweise wird der Elektronikentwurf durch eine 
Zusammenschaltung der Grundelemente (AND-, OR-, XOR-Gatter, 
Flip-Flops, etc.) dargestellt. Diese Grundelemente werden dabei von 
einer Bibliothek zur Verfügung gestellt. Innerhalb dieser Bibliothek 
sind die Eigenschaften der Grundelemente definiert. Diese bilden die 
Charakteristika der einzelnen Zellen der Zieltechnologie (z.B. 2 um 
Standardzellen-Prozeß der Fa. XYZ, FPGA 1.0 der Fa. ABC) in ver- 
einfachter Form nach. Zur Erstellung der strukturalen Beschreibung 
(Gatternetzliste) werden meistens graphische Eingabewerkzeuge 
("Schematic Entry") verwendet. 


Die Sichtweise "Verhalten" bedient sich dagegen vor allem einer Dar- 
stellung durch Boolesche Gleichungen (z.B. "y = (a AND b) XOR c") 
oder durch Funktionstabellen. 


Der Übergang von der Verhaltenssichtweise auf die strukturale und 
technologiespezifische Sichtweise erfolgt entweder durch einen manu- 
ellen Entwurf oder ein Syntheseprogramm. 


1.3.5 Schaltkreisebene 


Auch auf der Schaltkreisebene besteht die strukturale Sichtweise aus 
einer Netzliste. Diesmal sind allerdings keine logischen Gatter kombi- 
niert, sondern elektrische Bauelemente wie Transistoren, Kapazitäten 
und Widerstände. Einzelne Module werden nun nicht mehr durch eine 
logische Funktion mit einfachen Verzögerungen beschrieben, sondern 
durch ihren tatsächlichen Aufbau aus den Bauelementen. 


In der geometrischen Sicht werden elektronische Systeme durch Poly- 
gonzüge dargestellt, die beispielsweise unterschiedliche Dotierungs- 
schichten auf einem Halbleiter definieren. Die Verhaltenssicht verwen- 
det vornehmlich Differentialgleichungen zur Modellierung des Sy- 
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1 Entwurf elektronischer Systeme 


stemverhaltens. Dementsprechend aufwendig und rechenzeitintensiv 
sind die Simulationsalgorithmen. 


Die Signale auf Schaltkreisebene können im Gegensatz zur Logik- 
ebene prinzipiell beliebige Werte annehmen und weisen einen kon- 
tinuierlichen Verlauf über der Zeit auf, d.h. sie sind zeit- und wert- 
kontinuierlich. 


Abb. A-2 zeigt die typischen Ebenen beim Entwurf elektronischer Sy- 
steme im Überblick. 


Systemebene 


Control 


Algorithmische Ebene 


IN BR SERE 
IF (D=TRUE) THEN 
A:=AHtl 
ELSEEA :=A-1 
ENDIF 


Register-Transfer-Ebene 


Logikebene 
(Struktur) 


Schaltkreisebene 
(Struktur) 


AS ie d_59 


all. on 
sl CTL 


Schaltkreisebene 
(Geometrie) 


Abb. A-2: Ebenen beim Elektronik-Entwurf 
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A Einführung 


Jede der vorgestellten Entwurfssebenen hat ihren Zweck. Während auf 
den oberen Ebenen hohe Komplexitäten gut beherrschbar sind, bieten 
die unteren Ebenen mehr Details und höhere Genauigkeit. So eignen 
sich die Systemebene und die Algorithmische Ebene für die Doku- 
mentation und Simulation des Gesamtsystems, die Register-Transfer- 
Ebene für die Blocksimulation und synthesegerechte Modellierung 
und die Logikebene für Simulationen, mit denen beispielsweise die 
maximale Taktrate einer Schaltung bestimmt wird oder unerwünschte 
Impulse ("Spikes") detektiert werden. Auf jeder Ebene wird nur die 
benötigte Genauigkeit geboten; unwichtige Details sind nicht sichtbar 
(Abstraktionsprinzip). 


Selbstverständlich wird nicht immer eine eindeutige Einordnung einer 
Beschreibung in eine bestimmten Ebene gelingen, da die Grenzen 
nicht immer klar definierbar sind. Außerdem ist es möglich, daß die 
Beschreibung der einzelnen Komponenten eines komplexen, elektro- 
nischen Systems auf unterschiedlichen Abstraktionsebenen stattfindet 
("Multi-level-Beschreibung"). 
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2 Motivation für eine normierte 
Hardwarebeschreibungs- 
sprache 


Der Ablauf und die Randbedingungen beim Entwurf elektronischer 
Systeme haben sich in den letzten Jahren erheblich gewandelt. Dabei 
treten immer wieder die nachstehenden Probleme auf. 


2.1 Komplexität 


Die verbesserten Fertigungsmethoden der Halbleitertechnologie gestat- 
ten die Entwicklung hochintegrierter Bauelemente. Dies gilt sowohl 
für die anwendungsspezifischen Schaltkreise (z.B. Standardzellen- 
Schaltungen) als auch für die anwenderprogrammierbaren Bausteine 
(FPGAs, GALs, etc.) und die Standardbausteine (RAMs, Prozessoren, 
etc.). Selbst einfache Produkte, wie z.B. Haushaltsgeräte, enthalten 
heute umfangreiche elektronische Steuerungen. 


Der Elektronikentwickler muß also den Entwurf immer komplexer 
werdender Systeme beherrschen. Daneben erwarten die Kunden im- 
mer kürzere Innovationszyklen bei den Produkten. Dies hat folgende 
Konsequenzen: 


m Ein manueller Entwurf auf Logikebene ist durch graphische 
oder textuelle Eingabe von Gatternetzlisten nicht mehr be- 
herrschbar, da dieser Vorgang sehr fehleranfällig ist und Simu- 
lationen des Gesamtsystems auf Logikebene zu hohe Rechenzei- 
ten erfordern. Die Beschreibung des Systems muß deshalb auf 
einer abstrakteren Ebene vollzogen und durch geeignete Ent- 
wurfssoftware unterstützt werden. Die Überführung in die tiefer- 
liegenden Ebenen sollte weitgehend automatisiert sein. 
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A Einführung 


m Entwicklungsaufgaben werden auf mehrere Personen oder Pro- 
jektteams, die parallel arbeiten, aufgeteilt. Eine fehlerarme Kom- 
munikation zwischen den Entwicklern ist dabei sicherzustellen. 


7a Entwurfsfehler müssen so früh wie möglich entdeckt werden, um 
die Kosten und den Zeitbedarf für den notwendigen Neuentwurf 
("Redesign") gering zu halten. Um dies zu gewährleisten, sollten 
bereits Entwürfe der Systemebene oder der Algorithmischen 
Ebene simulierbar sein ("Simulierbare Spezifikation"). 


m Die Wiederverwendung von bestehenden Entwürfen kann die 
Entwicklungskosten und -zeiten verringern sowie das Entwick- 
lungsrisiko eingrenzen. Neben einer geeigneten Dokumentation 
erfordert die Wiederverwendung Entwürfe mit einem breiten 
Anwendungsbereich. Details der Implementierung müssen des- 
halb vermieden werden, d.h. daß beispielsweise der RT-Entwurf 
eines Halbleiterschaltkreises nicht spezifisch auf eine Fertigungs- 
technologie ausgerichtet sein darf. 


2.2 Datenaustausch 


Während des Entwurfs eines elektronischen Systems entsteht eine Viel- 
zahl von Informationen, die in der Summe seine Eigenschaften cha- 
rakterisieren. Dazu zählen beispielsweise Beschreibungen der System- 
funktionalität, der dynamischen Eigenschaften oder der Einsatzbedin- 
gungen. Ein Austausch dieser Informationen findet dabei statt zwi- 
schen: 


I Auftraggeber und -nehmer (Lasten- und Pflichtenheft), 
verschiedenen Entwicklern eines Projektteams, 
verschiedenen Entwurfsebenen, 


Entwurfsprogrammen verschiedener Hersteller, 


J"00nd 


unterschiedlichen Rechnersystemen. 


Aufwendige und fehlerträchtige Konvertierungen beim Austausch der 
Entwurfsdaten Können nur vermieden werden, wenn die Beschrei- 
bungsmittel herstellerübergreifend normiert sind, keine Spezifika eines 
bestimmten Rechnersystems enthalten sind und mehrere Entwurfs- 
ebenen abgedeckt werden. 
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2 Motivation für eine normierte Hardwarebeschreibungssprache 


Eine Fixierung auf eine herstellerspezifische Beschreibungssprache 
würde außerdem ein hohes wirtschaftliches Risiko mit sich bringen: 
Zum einen kann der Hersteller aus verschiedenen Gründen aus dem 
Markt austreten (Konkurs, Aufkauf durch ein Konkurrenzunterneh- 
men). Zum anderen zieht die Abhängigkeit von einer wenig verbreite- 
ten Beschreibungssprache eine bedeutende Einschränkung bei der 
Auswahl der Entwurfswerkzeuge nach sich. 


2.3 Dokumentation 


Die Lebensdauer eines elektronischen Systems ist oft höher als die 
Verfügbarkeit der Systementwickler. Eine Wartung des Systems, die 
Wiederverwendung von Systemteilen oder eine technische Modifi- 
kation (z.B. der Wechsel auf eine modernere Halbleitertechnologie) 
machen deshalb eine klare, langlebige und einheitliche Dokumenta- 
tion notwendig. Die Dokumentation sollte sowohl menschenlesbar als 
auch durch Rechnerwerkzeuge interpretierbar sein. 


Außerdem nimmt mit der steigenden Komplexität der Bausteine auch 
der Umfang der Dokumentation zu. Die Konsistenz und Vollständig- 
keit der Beschreibung rücken damit in den Vordergrund. 


Eine Verringerung oder Lösung der geschilderten Probleme beim 
Entwurf elektronischer Systeme ist durch den Einsatz einer Hardware- 
beschreibungssprache möglich. Eine solche Sprache, die gleichzeitig 
für strukturale Beschreibungen und Verhaltensbeschreibungen auf 
mehreren Entwurfsebenen eingesetzt werden kann, erleichtert den 
Übergang von der Aufgabenstellung zur Implementierung. Durch die 
Möglichkeit der Simulation dieser Verhaltensbeschreibung auf hoher 
Abstraktionsebene kann der Entwurf frühzeitig überprüft werden. Die 
Synthese der verfeinerten Verhaltensbeschreibung verkürzt die weitere 
Implementierungszeit ganz erheblich. Ein weiterer wesentlicher Vorteil 
ist die menschenlesbare Form, die eine Art Selbstdokumentation 
darstellt. Wird eine solche Hardwarebeschreibungssprache normiert, 
kann sie auch als Austauschformat zwischen verschiedenen Werkzeu- 
gen, Designteams und zwischen Auftraggeber und -nehmer dienen. 


Ein Beispiel für eine solche Hardwarebeschreibungssprache ist VHDL. 
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3  Geschichtliche Entwicklung 
von VHDL 


Die Anfänge der Entwicklung von VHDL! reichen bis in die frühen 
achtziger Jahre zurück. Im Rahmen des VHSIC?-Programms wurde in 
den USA vom Verteidigungsministerium (Department of Defense, 
DoD) nach einer Sprache zur Dokumentation elektronischer Systeme 
gesucht. Dadurch sollten die enormen Kosten für Wartung und techni- 
sche Nachbesserung bei militärischen Systemen, die etwa die Hälfte 
der Gesamtkosten ausmachten, reduziert werden. Besonderes Augen- 
merk wurde auf eine Möglichkeit zur sauberen und klaren Beschrei- 
bung von komplexen Schaltungen sowie auf die Austauschbarkeit von 
Modellen zwischen verschiedenen Entwicklungsgruppen gelegt. 


Im Rahmen eines vom VHSIC-Programm finanzierten Workshops in 
Woods Hole, Massachusetts, wurden diese Ziele zuerst diskutiert und 
dann in eine Vorgabe umgesetzt. Nach mehreren Vorversuchen beka- 
men im Juli 1983 die Firmen Intermetrics, IBM und Texas Instruments 
den Auftrag, die neue Sprache mit Programmen zu ihrer Unterstüt- 
zung zu entwickeln. Die Sprache sollte sich dabei an der existierenden 
Programmiersprache ADA anlehnen, da das DoD diese Sprache in 
weitem Umfang einsetzt. ADA-Programmierern werden daher etliche 
Übereinstimmungen und Ähnlichkeiten auffallen. 


Im August 1985 konnte eine erste Version der Hardwarebeschrei- 
bungssprache VHDL (VHDL Version 7.2) vorgestellt werden, die 
dann im Februar 1986 zur Standardisierung an das IEEE3 übergeben 


1 VHDL= VHSIC Hardware Description Language 
2 VHSIC = Very High Speed Integrated Circuit 


3 IEEE = Institute of Electrical and Electronics Engineers 
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3 Geschichtliche Entwicklung von VHDL 


wurde. Mit dieser Aufgabe wurde die VHDL Analysis and Stan- 
dardization Group (VASG) betraut. 


Unter verstärkter Beteiligung der Software- und Hardwarehersteller aus 
der CAE!-Industrie konnte VHDL zunehmend Anhänger gewinnen 
und wurde schließlich im Dezember 1987 als IEEE 1076-1987 zum 
ersten und bislang einzigen IEEE-Standard für Hardwarebeschrei- 
bungssprachen. Dieser Standard definiert allerdings nur die Syntax 
und Semantik der Sprache selbst, nicht jedoch ihre Anwendung bzw. 
ein einheitliches Vorgehen bei der Anwendung. Mittlerweile ist VHDL 
auch als ANSI?-Standard definiert. 


Erste 
Diskussionen 
Definition der 
Anforderungen 

Entwicklungsvertrag mit 
IBM, Intermetrics und TI 


Version 
72 


DoD übernimmt 
Standard 
wachsende Unterstützung 
durch CAE-Hersteller 
Überar- 
beitung 


1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 


Abb. A-3: Geschichtliche Entwicklung von VHDL 


Seit September 1988 müssen alle Elektronik-Zulieferer des DoD 
VHDL-Beschreibungen ihrer Komponenten und Subkomponenten 


bereitstellen. Ebenso sind VHDL-Modelle von Testumgebungen mit- 
zuliefern. 


CAE= Computer Aided Engineering 


2 ANSI= American National Standards Institute 
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A Einführung 


Nach den IEEE-Richtlinien muß ein Standard alle fünf Jahre überar- 
beitet werden, um nicht zu verfallen. Aus diesem Grund wurde im 
Zeitraum Anfang 1992 bis Mitte 1993 die Version IEEE 1076-1993 
definiert. Die Dokumentation des neuen Standards, das sog. Language 
Reference Manual (LRM), wird Mitte 1994 durch das IEEE herausge- 
geben werden. Die neue Version enthält im wesentlichen "kosmeti- 
sche" Änderungen gegenüber dem alten Standard, z.B. die Einführung 
eines XNOR-Operators. Im Teil B dieses Buches wird auf die Unter- 
schiede zwischen dem alten und dem neuen Standard hingewiesen. 


Seit Beginn der neunziger Jahre hat VHDL weltweit eine unerwartet 
große Zahl an Anhängern gefunden. Wurde die 1987er-Version noch 
durch das DoD finanziert, so ist der neue 1076-1993-Standard unter 
internationaler Beteiligung entstanden. Europa wirkt unter anderem 
über ESPRIT (ECIP?2) daran mit. Auch Asien (vor allem Japan) hat 
den VHDL-Standard akzeptiert. Die heutige Konkurrenz von VHDL 
besteht vor allem in der Verilog HDL, die in den USA weit verbreitet 
ist, und UDL/I, welches in Japan eingesetzt wird. 


Abb. A-4 zeigt eine Übersicht über die heute und in Zukunft verbrei- 
teten Hardwarebeschreibungssprachen (Ergebnis einer Umfrage unter 
Ingenieuren in den USA [JAI 93]; Mehrfachnennungen waren mög- 
lich): 


Veril 
VHDL "np  UDL/I Andere 


Abb. A-4: Anteile von HDLs heute (hell) und 
in Zukunft (dunkel) [Al 93] 
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4 Aufbau einer VHDL- 
Beschreibung 


Die Beschreibung eines VHDL-Modells besteht meist aus drei Teilen: 
einer Schnittstellenbeschreibung, einer oder mehreren Architekturen 
und einer oder mehreren Konfigurationen. VHDL-Beschreibungen 
können hierarchisch aufeinander aufbauen. 


4.1 Schnittstellenbeschreibung (Entity) 


In der Entity wird die Schnittstelle der zu modellierenden Komponen- 
te / des zu modellierenden Systems beschrieben, also die Ein- und 
Ausgänge sowie Konstanten, Unterprogramme und sonstige Verein- 
barungen, die auch für alle dieser Entity zugeordneten Architekturen 
gelten sollen. 


4.2 Architektur (Architecture) 


Eine Architektur enthält die Beschreibung der Funktionalität eines 
Modells. Hierfür gibt es verschiedene Möglichkeiten. Das Modell 
kann aus einer Verhaltensbeschreibung bestehen oder strukturalen 
Charakter (Netzliste) haben. Beide Möglichkeiten können miteinander 
kombiniert werden. Für eine Entity können mehrere Architekturen 
definiert werden, d.h. es können für eine Komponentenschnittstelle 
mehrere Beschreibungen auf unterschiedlichen Abstraktionsebenen 
oder verschiedene Entwurfsalternativen existieren. 
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A Einführung 
4.3 Konfiguration (Configuration) 


In der Konfiguration wird festgelegt, welche der beschriebenen Archi- 
tekturvarianten einer bestimmten Entity zugeordnet ist und welche 
Zuordnungen für die möglicherweise verwendeten Submodule in der 
Architektur gelten. Hier können auch hierarchisch den untergeordne- 
ten Entities bestimmte Architekturen zugeordnet werden; außerdem ist 
es möglich, Parameterwerte an hierarisch tieferliegende Komponenten 
zu übergeben. 


Entity: 
eine 
Schnittstelle 


Black Box 


Architecture: Verhaltens- 
Verhalten oder Struktur; beschreibung kombinierte 
eine oder mehrere Verhaltens- 
Alternativen Struktur- A2 und Struktur- 
beschreibung 


beschreibung 


A3 


Default- 


Architektur 
Configuration: (zuletzt 
beliebige compiliert) 
Anzahl Configuration 
Dan von Configuration 32 
Konfigurationen C1-3 
Abb. A-5: Entity, Architecture und Configuration 


4.4 Package 


Ein Package enthält Anweisungen wie Typ- oder Objektdeklarationen 
und die Beschreibung von Prozeduren und Funktionen, die in mehre- 
ren VHDL-Beschreibungen gebraucht werden. Zum Beispiel kann in 
einem Package der zu verwendende Logiktyp (zwei- oder mehrwertige 
Logik) mit allen korrespondierenden Operatoren definiert werden. 
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4 Aufbau einer VHDL-Beschreibung 


Vordefiniert sind bei VHDL die Packages standard (enthält den 
zweiwertigen Logiktyp "bit" sowie häufig zu verwendende Funk- 
tionen und Typen) und textio. 


In Abb. A-6 sind die wichtigsten Bestandteile einer VHDL-Beschrei- 
bung und ihre Aufgaben im Überblick dargestellt. 


Typen, oft gebrauchte Funktionen und 
PACKAGE Prozeduren, Komponenten, Konstanten 


Schnittstellenbeschreibung 
ENTITY (Parameter und E/A-Signale) 


Strukturale Beschreibung 
al EEU RE oder Verhaltensbeschreibung 


Auswahl der Architektur und der 
CONFIGURATION Submodule, Angabe von Parametern 


Abb. A-6: Grundbestandteile einer VHDL-Beschreibung 


4.5 Beispiel eines VHDL-Modells 


Anhand eines einfachen Beispieles soll der grundsätzliche Aufbau ei- 
nes VHDL-Modells vorab gezeigt werden. Das gewählte AND2-Gatter 
ist in seinem Aufbau sehr einfach, so daß noch keine Kenntnisse der 
VHDL-Syntax erforderlich sind, um die Funktion des Modells zu ver- 
stehen. 
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A Einführung 


Schnittstellenbeschreibung (Entity) 


ENTITY and2 IS 
PORT (inl,in2: IN bit; and_out: OUT bit); 


-- definiere Pins als Signale vom 
END and2; 


Typ "pit" 


Architektur (Architecture) 


ARCHITECTURE number_one OF and2 IS 

BEGIN 

and_out <= inl AND in2; -- Verhaltensbeschreibung 
END number_one; 


Konfiguration (Configuration) 


CONFIGURATION and2_config OF and2 IS 
FOR number_one -- verknuepfe Architektur 


END FOR; -- "number_one" mit Entity 


END and2_config; -- "and2" 
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5° Entwurfssichten in VHDL 


Im vorgestellten Y-Diagramm werden drei Sichten unterschieden. Die 
Sprache VHDL ermöglicht eine Beschreibung in der strukturalen Sicht 
und in der Verhaltenssicht. Bei VHDL-Modellen wird deshalb prin- 
zipiell zwischen: 


I Verhaltensmodellierung ("behavioral modeling") und 


I Strukturaler Modellierung ("structural modeling") 


unterschieden. Die Modellierung der geometrischen Sicht eines elek- 
tronischen Systems, z.B. die Beschreibung der Layoutdaten, wird von 
VHDL nicht unterstützt. 


5.1 Verhaltensmodellierung 


Bei dieser Modellierungsart wird das Verhalten einer Komponente 
durch die Reaktion der Ausgangssignale auf Änderungen der Ein- 
gangssignale beschrieben. Die Komponente verzweigt nicht weiter in 
Unterkomponenten. 


Am Beispiel eines Komparators werden die Vorteile der Verhaltens- 
modellierung deutlich. Der Komparator soll zwei Bit-Vektoren a und 
b miteinander vergleichen und eine logische '1' am Ausgang liefern, 
falls der Wert des Vektors a größer als der des Vektors b ist. 


Das nachfolgende VHDL-Modell kann, gesteuert durch den Parameter 
n, beliebig breite Bit-Vektoren miteinander vergleichen. Eine dieses 
Verhalten realisierende Schaltung, die aus vielen Gattern aufgebaut ist, 
kann in der Verhaltenssicht mit VHDL durch wenige Zeilen Quellcode 
beschrieben werden: 
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A Einführung 


ENTITY compare IS 
GENERIC (n : positive := 4); 
PORT (a, b : IN bit_vector (n-1 DOWNTO 0); 
result: OUT bit); 
END compare; 


ECTURE behavioral_1l OF compare IS 


ESS (a, b) 
EGIN 
IF a> b THEN 

result <= '1'; 
ELSE 
result <= '0'; 
END IF; 
END PROCESS; 
END behavioral_1; 


In der Verhaltenssichtweise werden zwei prinzipielle Beschreibungs- 
mittel unterschieden: 


I sequentielle Anweisungen ("sequential statements") und 


I nebenläufige Anweisungen ("concurrent statements"). 


Zur genaueren Betrachtung dieser Zusammenhänge soll ein Halbad- 
dierer dienen. Dessen Schnittstelle ist folgendermaßen aufgebaut: 


ENTITY halfadder IS 
PORT (sum_a, sum_b: IN bit; sum, carry: OUT bit); 
END halfadder; 


In sequentiellen oder auch prozeduralen Beschreibungen werden Kon- 
strukte wie Verzweigungen (IF-ELSIF-ELSE), Schleifen (LOOP) 
oder Unterprogrammaufrufe (FUNCTION, PROCEDURE) verwendet. 
Die einzelnen Anweisungen werden nacheinander (sequentiell) abge- 
arbeitet. Diese Beschreibungen ähneln den Quelltexten höherer Pro- 
grammiersprachen. 
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5 Entwurfssichten in VHDL 


Eine entsprechende Architektur für den Halbaddierer lautet: 


ECTURE behavioral_seq OF halfadder IS 


ESS (sum_a, sum_b) 

BEGIN 

IF (sum_a = '1'! AND sum_b = '1') TH 
sum <= '0'; carry <= '1'; 

‚SE 

IF (sum_a = '1'! OR sum_b = '1') THE 

sum <= '1'; carry <= '0'; 

ELSE 

sum <= '0'; carry <= '0'; 

END IF; 

END IF; 

END PROCESS; 

END behavioral_seg; 


Im Gegensatz zu den gängigen Programmiersprachen mit ihren se- 
quentiellen Konstrukten verfügt VHDL zusätzlich noch über neben- 
läufige Anweisungen, die es erlauben, parallel ablaufende Operationen 
zu beschreiben. Damit wird es möglich, die spezifischen Eigenschaften 
von Hardware (parallel arbeitende Funktionseinheiten) abzubilden. 


Nachstehend ist die Architektur des Halbaddierers in dieser Beschrei- 
bungsvariante gezeigt. Die beiden Verknüpfungen XOR und AND 
können dabei gleichzeitig aktiv sein: 


ARCHIT E behavioral_par OF halfadder IS 
BEGIN 

sum <= sum_a XOR sum_b; 

carry <= sum_a AND sum_b; 

END behavioral_par; 
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A Einführung 
5.2  Strukturale Modellierung 


Bei der strukturalen Modellierung werden die Eigenschaften eines 
Modells durch seinen inneren Aufbau aus Unterkomponenten darge- 
stellt. Die Eigenschaften der Unterkomponenten werden in unabhängi- 
gen VHDL-Modellen beschrieben. Diese stehen compiliert in Modell- 
bibliotheken ("Libraries") zur Verfügung. 


Für den Halbaddierer, der aus einem XOR2- und einem AND2-Gatter 
aufgebaut ist, ergibt sich beispielsweise folgende Beschreibung: 


ARCHITECTURE structural OF halfadder IS 
COMPONE xor2 
PORT (&1,. &2+ IN DIE} 3: QUT Bit}; 
END COMPONENT; 
COMPONENT and2 


PORT (c4, c5: IN bit; e6: QUT bit); 
END COMPONENT; 
EGIN 
xor_instance: xor2 PORT MAP (sum_a, sum_b, sum); 
and_instance: and2 PORT MAP (sum_a, sum_b, carry); 
END structural; 


Eine eindeutige Einordnung eines VHDL-Modells in eine der beiden 
Modellierungsarten ist nicht immer möglich, da VHDL die Ver- 
wendung beider Beschreibungsmöglichkeiten innerhalb eines Modells 
gestattet. 
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6  Entwurfsebenen in VHDL 


Die weiten Modellierungsmöglichkeiten von VHDL unterstützen Be- 
schreibungen in verschiedenen Entwurfsebenen, ausgehend von der 
Systemebene bis hinab zur Logikebene. Folgende drei Beschreibungs- 
ebenen haben dabei die größte Bedeutung: 


A Algorithmische Ebene, 
A Register-Transfer-Ebene, 
I Logikebene. 


Daneben finden sich in der VHDL-Literatur Ansätze, die zeigen, daß 
auch eine Modellierung auf Schaltkreisebene bedingt möglich ist (z.B. 
[HAR 91]). Die Praxisrelevanz dieser Ansätze ist jedoch gering. 


6.1 Algorithmische Ebene 


Ein Beispiel für eine Beschreibung auf Algorithmischer Ebene zeigt 
einen Ausschnitt aus der Architektur eines Schnittstellenbausteins. Der 
Baustein soll immer dann, wenn er von einem Controller eine Auf- 
forderung erhält, eine Adresse aus einem internen Register frühestens 
nach 10 ns auf den Bus legen. 


Diese Beschreibung enthält keine Angaben über die spätere Schal- 
tungsstruktur und keine Takt- oder Rücksetzsignale. 
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A Einführung 


ARCHITECTURE algorithmic_level OF io_ctrl IS 


BEGIN 


write_data_alg: PROC 


BEGIN 
wAIT UNTIL adr_request = '1'; 
wAIT FOR 10 ns; 
bus_adr <= int_adr; 

END PROCESS write_data_alg; 


END algorithmic_level; 


6.2  Register-Transfer-Ebene 


Um das obige Beispiel auf RT-Ebene darzustellen, wird ein Taktsignal 
(clk) und ggf. ein Rücksetzsignal hinzugefügt und die Operationen 
in Abhängigkeit von diesen Signalen beschrieben: 


ARCHITECTURE register_transfer_level OF io_ctrl IS 


BEGIN 


write_data_rtl : PROCESS (clk) 
E tmp : boolean; 


B 


IF rising_edge (clk) THEN 
IF ((adr_request = '1') AND (tmp = false)) TH 
tmp := trus; 

ELSIF (tmp = true) THEN 

bus_adr <= int_adr; 

tmp := false; 

END IF; 

END IF; 

END PROCESS write_data_rtl; 


END register_transfer_level; 


Hier wird, wenn bei einer aktiven Taktflanke ein gesetztes adr_ 
req-Signal entdeckt wird, zunächst die temporäre Variable tmp ge- 
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6 Entwurfsebenen in VHDL 


setzt, damit bei der nächsten aktiven Taktflanke (Wartezeit!) die 
Adresse auf den Bus geschrieben werden kann. Durch geeignete Wahl 
der Taktperiode ist sicherzustellen, daß die Wartezeit von mindestens 
10 ns eingehalten wird. 


Im Gegensatz zur Algorithmischen Ebene wird hier schon ein zeit- 
liches Schema für den Ablauf der Operationen vorgegeben und impli- 
zit eine Schaltungsstruktur beschrieben. 


Wie die beiden Beispielarchitekturen zeigen, werden Konstrukte der 
Verhaltensmodellierung sowohl auf Algorithmischer als auch auf Re- 
gister-Transfer-Ebene verwendet. 


6.3  Logikebene 


Die Eigenschaften eines elektronischen Systems werden auf der Lo- 
gikebene durch logische Verknüpfungen digitaler Signale und deren 
zeitliche Eigenschaften (i.a. durch Verzögerungszeiten der Ver- 
knüpfungen) beschrieben. Die Hardwarebeschreibungssprache VHDL 
besitzt dazu vordefinierte Operatoren (AND, OR, XOR, NOT etc.) für bi- 
näre Signale ('0', '1"') und gestattet die Ergänzung weiterer, benut- 
zerdefinierter Operatoren. Auch Konstrukte zur Modellierung zeitli- 
cher Eigenschaften werden bereitgestellt. Nachstehend ist beispielhaft 
die Beschreibung der Halbaddierer-Architektur auf der Logikebene in 
der Verhaltenssichtweise abgebildet. 


E logic_level OF halfadder IS 


sum <= sum_a XOR sum_b AFTER 3 ns; 
carry <= sum_a AND sum_b AFTER 2 ns; 


END logic_level; 


Die Darstellung in strukturaler Sicht entspricht der obigen Architektur 
"structural". Die Verzögerungszeiten ergeben sich hier aus den 
internen Verzögerungszeiten der beiden Subkomponenten. 
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7.1 Entwurfsablauf 


Abb. A-7 zeigt, wie der Entwurfsablauf unter Verwendung von VHDL 
aussehen Könnte: 


Entwurf Beschreibungsebenen Verifikation 


Aufgabenstellung, 
Spezifikation 
Erfassung der 


Aufgabenstellung manuelle 
Verhaltensbeschreibung Überprüfung 


auf algorithmischer Ebene 

(z.B. Ablaufdiagramm) Verhaltens- 

Verfeinerung des simulation 
Entwurfs 


>40 >-+o 


Verhaltensbeschreibung 
auf Register-Transfer-Ebene 


m (z.B. VHDL-Modell) 
= Synthese 
Sn, y a 
Netzliste auf Logikebene 
(herstellerunabhängig) 
CO Technology- 
Ze, Mapping . 
Netzliste auf Logikebene ‚Logik- 
(herstellerspezifisch, Simulation 
Erzeugung Test- z.B. VHDL, EDIF) Fehle- I 
E] bitmuster, simulation kı 
Z&ı Place & Route, 
Layout 
Layout 
Fertigung 
Abb. A-7: Entwurfsablauf mit VHDL 
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7.4.1 Erfassung der Spezifikation 


Am Anfang steht die Erfassung der Spezifikation, die i.d.R. vom Auf- 
traggeber in Form von Texten, Tabellen und Diagrammen an den 
Auftragnehmer übergeben wird. Diese Spezifikation enthält sowohl 
funktionale (Beschreibung der Schaltungsfunktion) als auch nicht- 
funktionale Angaben (Versorgungsspannung, Fertigungstechnologie, 
maximale Fläche und Verlustleistung, etc.). 


Nach einem ggf. vorhandenen Zwischenschritt über manuell erstellte 
Graphiken (Ablaufpläne, Flußdiagramme, etc.) erfolgte bisher der 
Entwurf des elektronischen Systems von Hand bis zu einer Netzliste, 
die die Verdrahtung vorhandener Module aus einer technologiespezi- 
fischen Bibliothek definiert. Diese Netzliste wurde durch Schematic- 
Entry-Werkzeuge in den Rechner eingegeben und im weiteren mit ent- 
sprechenden Programmen bis zum Layout umgesetzt. 


7.1.2 Beschreibung und Simulation auf System- oder 
Algorithmischer Ebene 


Heute ist man jedoch in der Lage, auch in den frühen Phasen des 
Elektronik-Entwurfs gezielt mit Rechnerunterstützung zu arbeiten. 
Durch Verwendung einer Hardwarebeschreibungssprache wie VHDL 
kann nun, ausgehend von einer nichtformalen Spezifikation, auf der 
abstrakten Ebene von Algorithmen und Funktionsblöcken bereits ein 
erstes VHDL-Modell der Schaltung erstellt werden. Eine anschließende 
Simulation der Schaltung auf dieser Ebene zeigt die Korrektheit des 
Entwurfs oder veranlaßt schon sehr frühzeitig notwendige Korrek- 
turen. 


Für viele Einsatzwecke existieren auch Werkzeuge, die eine graphische 
Eingabe des Entwurfs ermöglichen. Die Erstellung und Simulation 
abstrakter Verhaltensmodelle wird also graphisch unterstützt. Häufig 
bieten solche Programme auch die Möglichkeit, VHDL-Code auf 
Register-Transfer-Ebene zu generieren. Stehen solche Werkzeuge 
nicht zur Verfügung, muß das VHDL-Modell auf Register-Transfer- 
Ebene manuell erstellt werden. 
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7.1.8 Beschreibung auf Register-Transfer-Ebene 


Eine Beschreibung auf Algorithmischer Ebene kann von heute kom- 
merziell verfügbaren Synthesewerkzeugen nicht in eine Gatternetzliste 
umgesetzt werden. Diese Programme erwarten eine Beschreibung auf 
Register-Transfer-Ebene. Die bereits erstellte abstrakte Beschreibung 
muß also manuell verfeinert werden. Dabei ist die Kenntnis des zu 
verwendenden Synthesewerkzeuges und des von ihm unterstützten 
VHDL-Sprachumfanges äußerst wichtig. 


7.1.4 Logiksynthese und Technology Mapping 


Bei der anschließenden Synthese der VHDL-RTL-Beschreibung wird 
weitgehend automatisch eine noch technologieunabhängige Be- 
schreibung in der Logikebene erzeugt. Diese wird dann, nach Auswahl 
einer Zieltechnologie (z.B. Standardzellen-Prozeß 0.7 m der Firma 
XYZ), in eine technologiespezifische Gatternetzliste umgesetzt. Der 
Begriff "Technology Mapping" bezeichnet diesen Vorgang. Er wird 
meist durch das Synthesewerkzeug durchgeführt. Anschließende Ana- 
lysen können zeigen, ob die spezifizierten Eigenschaften, wie maximal 
zulässige Chipfläche, erreicht worden sind. Logiksimulationen lassen 
Aussagen über die Einhaltung von Zeitbedingungen zu. 


71.9 Erzeugung der Testbitmuster 


Nach der Erzeugung der Gatternetzliste müssen für den Produktions- 
test die Testbitmuster generiert werden. An dieser Stelle sind meist 
Modifikationen des Entwurfs notwendig, um eine gute Testbarkeit der 
Schaltung zu erreichen. Häufig wird der Entwickler auch bei dieser 
Tätigkeit durch Programme unterstützt, die das VHDL-Netzlistenmo- 
dell als Eingabe akzeptieren. 
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7.1.6 Layouterzeugung und Produktion 


Ausgehend von der technologiespezifischen VHDL-Gatternetzliste 
werden im abschließenden Entwurfsschritt die für die Produktion des 
elektronischen Systems notwendigen Layout- oder Programmierdaten 
erstellt. Für diesen Entwurfsschritt existiert eine Vielzahl kommerziel- 
ler Werkzeuge. 


Nach Erzeugung des Layouts können sehr genaue Aussagen über die 
Laufzeiten von Signalen gemacht werden, da jetzt die exakten geome- 
trischen Daten der Verdrahtung bekannt sind. Diese "realen" Verzöge- 
rungszeiten werden in die Logikebene zurückgereicht ("Backanno- 
tation"), so daß in der Logiksimulation die vom Layout abhängigen 
Einflüsse berücksichtigt werden können. 


7.2 VHDL-Software 


Im Bereich des Entwurfs elektronischer Systeme gibt es unterstützende 
Werkzeuge für Spezifikationserfassung und Dokumentation, funktio- 
nale Simulation auf verschiedenen Abstraktionsebenen, Schaltplan- 
eingabe, Fehlersimulation, Synthese, Layout oder Test. 


Nicht alle Entwurfsschritte sind sinnvoll mit VHDL durchzuführen. 
Die Schwerpunkte beim Einsatz von VHDL liegen heute im Bereich 
der Simulation von Verhaltensmodellen der Algorithmischen oder der 
Register-Transfer-Ebene sowie der Synthese. 


7.2.1 Texteditoren 


Der erste Schritt bei der Arbeit mit VHDL besteht in der Regel darin, 
VHDL-Quellcode einzugeben. Dazu kann jeder beliebige Texteditor 
verwendet werden (emacs, vi, textedit, etc.). Manche Software-Herstel- 
ler bieten im Rahmen ihrer VHDL-Programme einen eigenen VHDL- 
Editor an. Solche speziellen Editoren können beispielsweise VHDL- 
Schlüsselwörter (durch Fettdruck o. ä.) besonders hervorheben oder 
sprachspezifisch auf Eingaben reagieren, z.B. durch automatisches 
Schließen von Blöcken mit "END"-Anweisungen. 
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7.2.2 Graphische Benutzerschnittstellen 


Die Rechnerunterstützung in den frühen Entwurfsphasen gewinnt im- 
mer mehr an Bedeutung. Werkzeuge zur Erfassung eines Entwurfs auf 
hoher Abstraktionsebene finden zunehmende Verbreitung. Oft sind 
graphische Eingaben (Zeichnen von Automatengraphen oder Warte- 
schlangenmodellen, etc.) möglich. 


Eine frühzeitige Simulation des Entwurfs und die Ausgabe von (teil- 
weise garantiert synthetisierbarem) VHDL-Code sind weitere Plus- 
punkte für diese Art von Programmen. 


7.2.3 Simulatoren und Debugger 


VHDL-Simulatoren dienen dazu, Schaltungen mit vorgegebenen Sti- 
muli zu simulieren, d.h. die Reaktion aller internen Knoten und insbe- 
sondere der Ausgänge auf vorgegebene Änderungen der Eingänge zu 
ermitteln. Speziell zur Simulation von VHDL-Verhaltensmodellen 
gehört auch, daß der Zeitverlauf von VHDL-Objekten (Signalen und 
Variablen) dargestellt werden kann. 


Gerade wegen des nebenläufigen Konzepts einer Hardwarebeschrei- 
bungssprache sind zusätzlich Funktionen notwendig, die von typischen 
Software-Debuggern bekannt sind. Dazu zählt beispielsweise das Set- 
zen von sog. Breakpoints, welche die Simulation bei Eintreten einer 
bestimmten Bedingung (Erreichen einer vorgegebenen Simulations- 
zeit, spezielle Werte von Objekten, etc.) anhalten. 


Die meisten kommerziell angebotenen VHDL-Simulatoren können in- 
zwischen jedes beliebige VHDL-Modell verarbeiten (100%-ige Code- 
abdeckung). Sieht man von wenigen Details ab, die vor allem auf Un- 
genauigkeiten der VHDL-Norm zurückzuführen sind, Kann man von 
einer einheitlichen Interpretation eines VHDL-Modells durch ver- 
schiedene Simulatoren ausgehen. 


Erwähnt werden sollte noch, daß auf Logikebene spezialisierte Simula- 
toren zur Zeit noch deutlich schneller als VHDL-Simulatoren sind. Die 
Hersteller der VHDL-Simulatoren arbeiten allerdings intensiv an einer 
Performance-Verbesserung durch neue Simulationstechniken (siehe 
Teil C) bzw. bieten eine Anbindung ihrer Werkzeuge an spezialisierte 
"Gate-Level-Simulatoren" an. 
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7.2.4 Syntheseprogramme 


Syntheseprogramme können am meisten dazu beitragen, den Entwurf 
elektronischer Systeme produktiver zu gestalten. Sie setzen eine funk- 
tionale VHDL-Beschreibung (auf Register-Transfer-Ebene) in eine 
Netzliste auf Logikebene um. Zu diesem Zweck ist eine technologie- 
spezifische Gatterbibliothek erforderlich. Sie enthält Informationen 
über Fläche, Laufzeiten, Verlustleistung usw. der einzelnen Gatter. 


Ein wesentlicher Gesichtspunkt bei der Bewertung eines Synthesepro- 
grammes ist der Umfang von VHDL-Konstrukten, die synthetisiert 
werden können. Im Gegensatz zur Simulation kann bei der Synthese 
nicht der komplette Sprachumfang verarbeitet werden. Dies liegt v.a. 
daran, daß VHDL nicht primär auf Synthesezwecke hin ausgerichtet 
wurde, sondern auch viele Konstrukte enthält, die prinzipiell nicht in 
Hardware umgesetzt werden können. 


Außerdem ist zu überprüfen, ob für eine gewünschte Zieltechnologie 
die werkzeugspezifische Gatterbibliothek verfügbar ist. 
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8 Bewertung von VHDL 


Die vorhergehenden Kapitel haben gezeigt, daß der Einsatz einer 
normierten Hardwarebeschreibungssprache viele Vorteile für den Ent- 
wurf komplexer Elektronik bietet. Der erste Teil des Buches sollte 
jedoch nicht nur euphorisch VHDL loben, sondern auch einige kriti- 
sche Worte enthalten. Im folgenden finden sich deshalb einige grund- 
sätzliche Bemerkungen zu VHDL, die allerdings nicht immer objektiv 
möglich sind. Zum Beispiel kann die umfangreiche Syntax sowohl als 
Vorteil (viele Modellierungsmöglichkeiten), als auch als Nachteil (ho- 
her Einarbeitungsaufwand) empfunden werden. 


8.1 Vorteile von VHDL 
8.1.1 Vielseitigkeit 


Zweifellos als Vorteil kann es angesehen werden, daß VHDL eine 
Sprache für viele Zwecke ist. 


VHDL ist sowohl für die Spezifikation und Simulation wie auch als 
Ein- und Ausgabesprache für die Synthese geeignet. Die menschenles- 
bare Form eignet sich gut zur Dokumentation. Beispielsweise bietet 
VHDL über benutzerdefinierte Attribute die Möglichkeit, entwurfsbe- 
gleitende Angaben, wie Vorgaben zur Fläche oder Laufzeit, zu doku- 
mentieren. 


Schließlich ist durch die firmenunabhängige Normierung der Sprache 
ein Datenaustausch zwischen verschiedenen Programmen, zwischen 
verschiedenen Entwurfsebenen, zwischen verschiedenen Projektteams 
und zwischen Entwickler und Hersteller möglich (siehe Abb. A-8). 
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Technologie A | |Technologie B [Technologie C [Technologie D | [Technologie C | |Technologie E 
(FPGAs (Gate-Arrays) (Stand. Zellen) (FPGAs) (Stand. Zellen) | (Stand. Zellen) 
| I N I 4 


CAD- CAD- 
Programm I Programm Il Programm Ill Programm IV 


andere 


a >» Beschreibungssprachen > NAD 


Abb. A-8: Datenaustausch zwischen CAD-Programmen 
und Halbleiterherstellern 


8.1.2 Programmunabhängigkeit 


Neben VHDL gibt es auch noch eine Reihe anderer Hardwarebeschrei- 
bungssprachen und Datenformate. Man unterscheidet dabei zwischen 
programmspezifischen und nicht-programmspezifischen Sprachen 
bzw. Formaten. Erstere sind an die Programme eines bestimmten 
Software-Herstellers gebunden und werden meist nicht von den Pro- 
grammen anderer Hersteller unterstützt. Auch die heutige Hauptkon- 
kurrenz von VHDL, die Verilog HDL, war lange Zeit herstellerspezi- 
fisch und hat sich erst in neuerer Zeit zu einer unabhängigen HDL 
entwickelt. 


VHDL ist programmunabhängig. Es gibt mittlerweile eine Vielzahl 
von Software-Anbietern, die für viele Entwurfsschritte eine Lösung un- 
ter Einsatz von VHDL anbieten. Man kann somit unter mehreren 
Alternativen die für die geplante Anwendung optimale Software aus- 
wählen. 


Außerdem wurde bei der Definition der Sprache VHDL sehr stark auf 
die Unabhängigkeit von einem bestimmten Rechnersystem geachtet. 
Die systemabhängigen Aspekte werden in Packages gekapselt, das 
VHDL-Modell selbst ist unabhängig vom eingesetzten Rechnersystem 
und damit (fast immer) portierbar. 
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8.1.3 Technologieunabhängigkeit 


VHDL ist technologieunabhängig. Die Entscheidung für eine be- 
stimmte Technologie (FPGA, Gate-Array, Standardzellen, etc.) muß 
erst zu einem relativ späten Zeitpunkt des Entwurfs getroffen werden. 
Ein späteres Umschwenken auf eine andere Technologie verursacht 
kein komplettes Redesign. 


Auch die Offenheit der Sprache bzw. die umfangreichen Modellie- 
rungsmöglichkeiten tragen wesentlich zur Technologieunabhängigkeit 
bei. Durch die Freiheit zur Definition von: 


I benutzereigenen Logiktypen mit entsprechenden Operatoren, 


I Auflösungsfunktionen, die technologiespezifische Signalver- 
knüpfungen (wired-or, wired-and, etc.) modellieren, 


I neuen, bei strukturalen Modellen eingesetzten Komponenten- 
bibliotheken 


können die spezifischen Eigenschaften bestimmter Technologien mit 
VHDL abgebildet werden. Man sagt deshalb auch, VHDL arbeitet 
technologieunterstützend. 


8.1.4 Modellierungsmöglichkeiten 


VHDL stellt zahlreiche Konstrukte zur Beschreibung von Schaltungen 
und Systemen zur Verfügung. Mit diesen Konstrukten lassen sich Mo- 
delle auf verschiedenen Beschreibungsebenen erstellen: Algorith- 
mische Ebene, Register-Transfer-Ebene und Logikebene. VHDL-Mo- 
delle können dabei Unterkomponenten verschiedener Entwurfssichten 
und -ebenen enthalten. Bei der strukturalen Modellierung kann eine 
mehrstufige Hierarchie implementiert werden. 


Beschreibungen auf abstraktem Niveau haben mehrere Vorteile: 


I sie sind kompakt und überschaubar, der Überblick über den ge- 
samten Entwurf bleibt erhalten, 


I sie ermöglichen kürzere Entwicklungszeiten, 


I sie benötigen weniger Rechenzeit bei der Simulation, 


I sie erlauben eine frühzeitige Verifikation. 
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Durch Kombination mit detaillierteren Beschreibungen ist eine ebe- 
nenübergreifende Simulation (sog. "Multi-Level-Simulation") mög- 
lich. Einzelne Projektteams können deshalb weitgehend unabhängig 
voneinander arbeiten, da eine Gesamtsimulation unterschiedlich weit 
verfeinerter Modelle durchführbar ist. Außerdem gestattet die Multi- 
Level-Simulation die Kontrolle eines Entwurfsschrittes, indem die Mo- 
delle vor und nach dem Entwurfsschritt durch gemeinsame Simulation 
miteinander verglichen werden können. 


8.1.5 Unterstützung des Entwurfs komplexer 
Schaltungen 


Die durch VHDL verstärkte Verbreitung von Synthesewerkzeugen er- 
laubt ein Umschwenken auf eine neue und produktivere Entwurfs- 
methodik mit strukturierter Top-Down-Vorgehensweise. Wesentliche 
Aspekte dabei sind: 


I Da die Spezifikation eine simulierbare Beschreibung darstellt, 
kann der Entwurf frühzeitig überprüft werden, 


I Verhaltensbeschreibungen in einer Hardwarebeschreibungsspra- 
che können synthetisiert werden, 


71 Zahlreiche Sprachkonstrukte zur Parametrisierung von Model- 
len erlauben ein unkompliziertes Variantendesign, 


A Die Entwicklung wiederverwendbarer Modelle wird unterstützt, 


I Es bestehen Umsetzungsmöglichkeiten auf verschiedene Tech- 
nologien. 


Alles zusammen führt zur Beherrschung von komplexeren Schaltun- 
gen und zu einer wesentlich verkürzten Entwicklungszeit. 


8.1.6 Selbstdokumentation 


VHDL ist eine menschenlesbare Sprache. Die Syntax ist sehr ausführ- 
lich gehalten und besitzt viele selbsterklärende Befehle. Dadurch ent- 
steht eine Art Selbstdokumentation. 


Bei der zusätzlichen Wahl von geeigneten Objektnamen enthält eine 
ohne weitere Kommentare versehene Beschreibung durchaus genü- 


© G. Lehmann/B. Wunder/M. Selz 49 


A Einführung 


gend Informationen, um zu einem späteren Zeitpunkt noch ohne Pro- 
bleme interpretiert werden zu können. 


8.2 Nachteile von VHDL 
8.2.1 Mehr als eine Sprache: Eine neue Methodik 


Mit dem Einsatz von VHDL beim Entwurf ist weit mehr verbunden als 
bei der Einführung eines neuen Programmes oder eines neuen For- 
mates. Der gesamte Entwurfsablauf hat sich vom manuellen Entwurf 
mit Schematic Entry auf Logikebene zur Schaltungsbeschreibung auf 
RT-Ebene mit anschließender Synthese gewandelt. 


Dies hat mehrere Folgen: 


a Es ist ein grundsätzlich neuer Entwurfsstil einzuführen, verbun- 
den mit einem Umdenken bei den Hardware-Entwicklern. Er- 
fahrungsgemäß haben aber gerade Entwickler, die in ihrer Aus- 
bildung nicht mit modernen Programmiersprachen und der er- 
forderlichen strukturierten Vorgehensweise vertraut gemacht 
wurden, dabei große Probleme: "We don't know if to 'harden' a 
Software engineer or to 'soften' a Hardware engineer", [BUR 
92]. 


I Die erforderlichen Aus- und Weiterbildungsmaßnahmen verur- 
sachen Kosten und Ausfallzeiten. 


I Die anfallenden Kosten für die Neuanschaffung einer ganzen 
Werkzeugpalette (Workstations, Speicher, Lizenzgebühren für 
Software, etc.) sind enorm. 


8.2.2 Modellierung analoger Systeme 


VHDL verfügt zwar über umfangreiche Beschreibungsmittel für digi- 
tale, elektronische Systeme, bietet aber auch in der neuen Norm 
(VHDL'93) keine Konstrukte zur Modellierung analoger elektroni- 
scher Systeme. Das gleiche gilt für Komponenten mit mechanischen, 
optischen, thermischen, akustischen oder hydraulischen Eigenschaften 
und Funktionen. Damit ist VHDL keine Sprache, die die vollständige 
Verhaltensmodellierung eines technischen Systems zuläßt. 
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Aktuelle Bestrebungen zielen allerdings auf die Definition einer erwei- 
terten VHDL-Norm (IEEE 1076.1, AHDL), die die Modellierung ana- 
loger Schaltkreise mit wert- und zeitkontinuierlichen Signalen gestat- 
tet. 


8.2.3 Komplexität 


Die Komplexität der Sprache VHDL wird als Vorteil aufgrund der vie- 
len Modellierungsmöglichkeiten angesehen, bringt aber auch einige 
Nachteile mit sich: 


m VHDL erfordert einen hohen Einarbeitungsaufwand. Es ist mit 
einer weitaus längeren Einarbeitungszeit als bei anderen Spra- 
chen zu rechnen. Insbesondere muß ein geeigneter Modellie- 
rungsstil eingeübt werden. 


m Das Verhalten eines komplexen VHDL-Modells in der Simula- 
tion ist für den VHDL-Neuling kaum nachvollziehbar, da die 
zugehörigen Mechanismen (z.B. "preemption" von Ereignis- 
listen) nicht von gängigen Programmiersprachen abgeleitet wer- 
den können. 


m Die Semantik wurde in der ursprünglichen Version 1987 an vie- 
len Stellen nicht eindeutig und klar genug festgelegt. In der 
Überarbeitung der Sprache wurden 1993 einige dieser Stellen 
beseitigt und die Interpretation damit vereinheitlicht. 


Erschwerend zu diesen Problemen kommt, daß das Nachschlagewerk 
für VHDL, das "Language Reference Manual" (LRM), als eines der am 
schwersten zu lesenden Bücher der Welt einzustufen ist ("The base 
type of a type is the type itself", [IEE 88]). 


8.2.4 Synthese-Subsets 


VHDL ist als Sprache in der Syntax und Simulationssemantik nor- 
miert, nicht jedoch für die Anwendung als Eingabeformat für Syn- 
thesewerkzeuge. Außerdem enthält VHDL Konstrukte, die sich prin- 
zipiell nicht in eine Hardware-Realisierung umsetzen lassen. Darüber 
hinaus unterstützt jedes Synthesewerkzeug einen etwas anderen 
VHDL-Sprachumfang (VHDL-Subset) und erfordert einen spezifi- 
schen Modellierungsstil. Daraus resultieren folgende Probleme: 
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m VHDL-Modelle müssen auf ein spezielles Synthesewerkzeug 
zugeschnitten sein. Dies verhindert einen unkomplizierten 
Wechsel des Werkzeugs und erhöht die Abhängigkeit vom 
Werkzeushersteller. 


m Der Elektronik-Entwickler muß die Anforderungen des gewähl- 
ten Werkzeuges kennen und von Anfang an bei der Modeller- 
stellung berücksichtigen. 


8.2.5 Noch keine umfassende Unterstützung 


Obwohl seit Ende der 80er Jahre die Unterstützung von VHDL durch 
Werkzeuge vieler Software-Hersteller enorm zugenommen hat, ist die 
heutige Situation noch nicht zufriedenstellend. 


Ein Mangel besteht vor allem bei den Simulations- und Synthesebi- 
bliotheken für logische Gatter und Standardbausteine. Jede neue 
Technologie erzwingt eine komplette Neufassung der umfangreichen 
Daten, die oft erst zeitverzögert zur Verfügung gestellt werden. In 
diesem Punkt ist die schon länger existierende Hardwarebeschrei- 
bungssprache Verilog der neueren Sprache VHDL überlegen, da die 
Zahl der bestehenden Verilog-Bibliotheken noch weitaus größer ist. 


8.2.6 Ausführlichkeit 


Die Ausführlichkeit der Sprache VHDL kann auch als Nachteil emp- 
funden werden. Der oft als "zu geschwätzig" empfundene Stil verur- 
sacht lange und umständliche Beschreibungen. Vor allem bei der ma- 
nuellen Modellerstellung verhindert der Umfang des einzugebenden 
Textes ein schnelles Vorgehen. 
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1 Allgemeines 


1.1 VHDL’87 oder VHDL’93 ? 


Das Erscheinen dieses Buches fällt mit einem wichtigen Zeitpunkt zu- 
sammen: Nach der ersten Überarbeitung der VHDL-Norm (IEEE- 
Standard 1076) in den Jahren 1992 und 1993, fünf Jahre nach der 
Verabschiedung, sind die Softwarehersteller dabei, ihre Programme 
der neuen Syntax anzupassen. Nach und nach werden die VHDL’93- 
kompatiblen Programme ältere Versionen ersetzen. 


Welcher Standard soll nun in einem "aktuellen" Buch beschrieben 
werden? VHDL’‘87, mit dem wahrscheinlich zum Zeitpunkt des Er- 
scheinens die meisten Entwickler noch arbeiten, oder VHDL’93, das in 
den nächsten Jahren ältere Programmversionen ablösen wird. Er- 
schwert wird die Problematik durch die Tatsache, daß die beiden Ver- 
sionen nicht vollkommen aufwärtskompatibel sind. Es wurden nämlich 
auch einige Konstrukte aus der alten Syntax eliminiert. 


Letztendlich haben sich die Autoren entschieden, der momentan hete- 
rogenen Situation Rechnung zu tragen und beide Versionen zu be- 
schreiben. Dort, wo nichts besonderes vermerkt ist, gilt die Syntax für 
VHDL’87 und VHDL‘93. Teile, die nur für VHDL’‘87 gelten, sind mit 
dem Zeichen Yg7, Teile der neuen Norm mit Yg93 gekennzeichnet. 


Zu den wesentlichen Neuerungen im 93-er Standard gehören: 


ein erweiterter Zeichensatz, 

Gruppen, 

globale Variablen, 

Schiebe- und Rotierfunktionen für Vektoren, 
dem Simulationszyklus nachgestellte Prozesse, 


Ja0o0u00n 


Ergänzung und Elimination einiger vordefinierter Attribute. 
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1.2 Vorgehensweise und Nomenklatur 


Die Vorgehensweise dieses Buches ist eine etwas andere als die her- 
kömmlicher VHDL-Bücher. So soll die Hardwarebeschreibungsspra- 
che ausgehend von der Basis, dem benutzten Zeichenvorrat, erläutert 
werden. Mit der Beschreibung von Sprachelementen, Daten und Ob- 
jekten wird die Basis für die im weiteren folgende Darstellung der 
Befehle zur strukturalen Modellierung und zur Verhaltensmodellie- 
rung gelegt. Dem Simulationsablauf und der Konfiguration in VHDL 
ist jeweils ein eigenes Kapitel gewidmet. Den Abschluß des Syntaxteils 
bildet ein Kapitel über spezielle Modellierungstechniken. 


Für eine einsichtige Darstellung von Syntaxregeln und VHDL-Beispie- 
len (lauffähiger Quellcode) ist eine klare und durchgehende Nomen- 
klatur erforderlich. 


Die üblicherweise zur Syntaxbeschreibung verwendete BNF (Backus 
Naur Form) erweist sich sehr wohl als sinnvoll zur vollständigen und 
korrekten Definition einer Syntax. Zum Erlernen einer Sprache er- 
scheint uns diese BNF jedoch ungeeignet. Deshalb entschieden wir 
uns, zur Syntaxbeschreibung eine vereinfachte Variante der BNF zu 
wählen, in der folgende Nomenklatur gilt: 


a anstelle von formalen, hierarchisch deduzierten Definitionen ste- 
hen mehrere konkrete Einzeldefinitionen (nur in wenigen Fällen 
wird, gekennzeichnet durch kursive Formatierung, auf vorher 
eingeführte Definitionen verwiesen), 


A VHDL-Schlüsselwörter sind immer in Großbuchstaben verfaßt, 


I frei wählbare Bezeichner (Typnamen, Objektnamen, ...) oder 
Ausdrücke sind klein geschrieben und tragen selbstbeschreiben- 
de Namen, 


A optionale Angaben stehen in eckigen Klammern [], 


I beliebig oft wiederholbare Angaben stehen in geschweiften 
Klammern {}. 


© G. Lehmann/B. Wunder/M. Selz 55 


2 Sprachelemente 


2.1 Sprachaufbau 

Aus dem Zeichensatzvorrat werden durch gezielte Verknüpfungen 
und Kombinationen die lexikalischen Elemente und daraus wiederum 
die VHDL-Sprachkonstrukte aufgebaut. Diese ergeben in ihrem Zu- 


sammenwirken die Design-Einheiten ("design units"), welche die Kom- 
ponenten der VHDL-Modelle bilden. 


Dieser Aufbau der Modelle aus elementaren Elementen kann mit dem 
Aufbau der Materie aus Atomen und Molekülen verglichen werden. 
Abb. B-1 verdeutlicht den Sprachaufbau graphisch. 


Grundzeichenvorrat 
Lexikalische Elemente 
Sprachkonstrukte 


Design-Einheiten 


VHDL-Modell 


Abb. B-1: VHDL-Sprachaufbau 
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2.2 Zeichensatz 


Der Zeichensatz von VHDL umfaßt in der ursprünglichen Version 
(V 87) nur 128 Zeichen, entsprechend der 7-Bit ISO 83-Norm. Neben 
den herkömmlichen Groß- und Kleinbuchstaben sind die Ziffern O bis 
9, ein gewisser Satz an Sonderzeichen sowie unsichtbare Forma- 
tierungszeichen enthalten. 


Der Umfang des Zeichensatzes von Vg7 wird am Beispiel der Dekla- 
ration für den Aufzähltyp character gezeigt: 


E character 
L, SOH, 
HT, 
DC1, 
EM, 
rıv 
.r 
r ) r Pr 


Ele, 


'9', 


Mit der neuen VHDL-Norm wurde die Zeichendarstellung von 7 auf 8 
Bit, der Zeichenvorrat damit auf insgesamt 256 Zeichen entsprechend 
der Norm ISO 8859-1 erweitert. Er umfaßt nunmehr auch landesspezi- 
fische Umlaute und weitere Sonderzeichen. Der Umfang des neuen 
Zeichensatzes (Yg3) wird am Beispiel der character-Typdeklara- 
tion gezeigt: 
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E character IS ( 
-- alle Zeichen aus VHDL'87 


c129, C130, cC131, C132, 
c137, C138, C139, C140, 
c145, cC146, C147, cC148, 
c153, C154, cC155, C156, 
eh, Re e ıE1, 'at, 
'o', van, 
'+tt, 21, 
ılı 

r 


'Ä', 


Die durch ein ' Ye '-gekennzeichneten Zeichen konnten mit dem Zei- 
chensatz des verwendeten Textverarbeitungssystems leider nicht darge- 
stellt werden. 


VHDL ist im allgemeinen (syntaktische Elemente und Bezeichner) 
nicht case-sensitiv, d.h. Groß- und Kleinschreibung wird von den An- 
wendungsprogrammen nicht unterschieden. Ein Bezeichner namens 
inputl2 hat die gleiche Bedeutung wie INPUT12 oder Input12. 


Eine Ausnahme von dieser Regel bilden lediglich die "extended identi- 
fier" (93), sowie Einzelzeichen ("character") und Zeichenketten 
("strings"). 


Die Eigenschaft der "case-Insensitivität" bietet sich an, um eine bessere 
Lesbarkeit des VHDL-Codes zu erreichen. Eine von Anfang an konse- 
quent beibehaltene Groß- und Kleinschreibung von syntaktischen Ele- 
menten zahlt sich mit Sicherheit aus. In diesem Buch werden zum Bei- 
spiel Schlüsselwörter und Attribute der VHDL-Syntax stets groß ge- 
schrieben. 
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Damit VHDL-Modelle auch auf Rechnern angelegt werden können, 
bei denen die Eingabe der drei Sonderzeichen " # | nicht möglich 
ist, erlaubt VHDL die Ersetzung durch die Zeichen % : ! in den 
Anweisungen. Ein Beispiel für eine Ersetzung: 


E value_string IS -—- Ausschnitt aus einem 
WHEN "high" | "undefined" => -- VHDL-Modell 


E value_string IS -- aequivalente 
WHEN $high% ! undefined? => -- Beschreibung 


2.3 Lexikalische Elemente 


Aus dem Zeichenvorrat, sozusagen den Atomen von VHDL, werden 
zunächst die sog. "lexikalischen Elemente" gebildet. Lexikalische Ele- 
mente sind also Kombinationen von Elementen des Zeichenvorrates, 
die eine bestimmte Bedeutung haben. Um beim Vergleich mit der 
Chemie zu bleiben, könnte man die lexikalischen Elemente etwa als 
Moleküle betrachten. Die Bedeutung der lexikalischen Elemente läßt 
sich in verschiedene Sprachelemente aufteilen. Aus der richtigen 
Kombination dieser Sprachelemente setzen sich wiederum die Design- 
Einheiten zusammen. 


Lexikalische Elemente können in folgende Gruppen eingeteilt werden: 


2.3.1 Kommentare 


Kommentare dienen lediglich zur besseren Lesbarkeit von VHDL- 
Quellcode; sie haben keinerlei Bedeutung für die Funktion eines Mo- 
dells. Eine Ausnahme hiervon bilden Steueranweisungen für Synthese- 
werkzeuge, die oft innerhalb eines Kommentares stehen. 


Das Kommentarzeichen ist der doppelte Bindestrich ("--"); er kenn- 
zeichnet den Anfang eines Kommentares, der dann bis zum Ende der 
Zeile reicht. Das Kommentarzeichen kann zu Beginn einer Zeile oder 
nach VHDL-Anweisungen stehen. 
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Ein Kommentar beginnt mit -- und reicht 


ENTITY inv IS bis zum Zeilenende. Er kann alle 
moeglichen Zeichen (*'_>-<) beinhalten. 


2.3.2 Bezeichner 


Bezeichner, im Englischen "identifier", sind Namen von Design-Ein- 
heiten, Objekten, Objekttypen, Komponenten, Funktionen, etc. Bei der 
Wahl von Bezeichnern sind folgende Regeln zu beachten: 


A Bezeichner bestehen aus Buchstaben, Ziffern und einzelnen Un- 
terstrichen; sie dürfen keine Leer- und Sonderzeichen enthalten, 


A Bezeichner sind case-insensitiv, 


I 


das erste Zeichen eines Bezeichners muß ein Buchstabe sein, 


m der Unterstrich ("_") darf nicht am Anfang oder Ende des Be- 
zeichners und nicht zweimal unmittelbar aufeinanderfolgend 
verwendet werden, 


7a Bezeichner dürfen keine reservierten Worte sein. 


Diese Regeln, v.a. hinsichtlich des ersten Zeichens und des Sonderzei- 
chenverbots, stellen doch eine erhebliche Einschränkung dar. Modelle, 
z.B. von digitalen Grundbausteinen, können nicht ihre technische Be- 
zeichnung als Bezeichner tragen. Demnach sind MODULE#09, 8085 
und 74LS11 illegale Namen in YVg7. Diese Einschränkung bei der 
Wahl von Bezeichnern wurde mit der Einführung der sog. "extended 
identifier" in Vg3 aufgehoben. Diese erweiterten Bezeichner stehen in- 
nerhalb nach links geneigter Schrägstriche ("\...\") und weisen fol- 
gende Eigenschaften auf: 


I sie unterscheiden sich von herkömmlichen Bezeichnern gleichen 
Wortlauts, 


A sie sind case-sensitiv, 


I Graphikzeichen (jedoch keine Formatierungszeichen) dürfen 
enthalten sein, 


I benachbarte Schrägstriche repräsentieren einen Schrägstrich im 
Namen, 


A sie dürfen mit einer Ziffer beginnen, 
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A sie dürfen Leerzeichen enthalten, 


A sie dürfen mehr als einen Unterstrich in Folge beinhalten, 


A sie dürfen mit reservierten Worten identisch sein. 


Durch die Verwendung der Schrägstriche lassen sich also mehr und 
aussagekräftigere Bezeichner verwenden als vorher. Einige Beispiele 
für normale und extended identifier: 


Normale Bezeichner (Identifier) 
ntische Bezeichner 
illegal: 1.Zeichen k. Buchstabe 
illegal: Reservierte Wort 


node_a, xyz, compl2 
abc, Abc, ABC 
12_in_bus 

port, buffer 


bus__parity 
bus_#12 
sign a to £ 


illegal: 
illegal: 
illegal: 


Mehr als 1 Unterstrich 
Sonderzeichen 
Leerzeichen 


Extended Identifier ! nur VHDL'93 ! 
Verschiedene Bezeichner 

l.Zeichen ist Ziffer 
Reservierte Wort 

Mehr als ein Unterstrich 
Sonderzeichen 

Leerzeichen 


\name_of_sign\ 
\abc\, \Abc\, \ABC\ 
\12_in_bus\, \74LS11\ -- legal: 


\port\, \buffer\ 
\bus__parity\ 
\bus_#12\ 

\sign a to £\ 


legal: 
legal: 
legal: 
legal: 


2.3.3 Reservierte Wörter 


Reservierte Wörter haben eine bestimmte Bedeutung für die Syntax 
und dürfen deshalb nicht als (normale) Bezeichner verwendet werden. 
Es handelt sich dabei um Operatoren, Befehle und sonstige VHDL- 
Schlüsselwörter. Schlüsselwörter der neuen Norm (93) sind in der 
folgenden Aufzählung gekennzeichnet. 


ABS ARRAY BUFFER 

ACCESS ASSERT BUS 

AFTER ATTRIBUTE 

ALIAS CASE 

ALL BEGIN COMPONENT 

AND BLOCK CONFIGURATION 
ARCHITECTURE BODY CONSTANT 
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MAP ROR (93) 
DISCONNECT MOD 
DOWNTO SELECT 

NAND SEVERITY 
ELSE NEW SHARED (93) 
ELSIF NEXT SIGNAL 
END NOR LA (v93) 
ENTITY NOT ST (v93) 
EXIT NULL SRA (263) 
en or SRL (v 93) 
FOR ON SUBTYPE 
FUNCTION OPEN 

OR a 
GENERATE OTHERS TRANSPORT 
GENERIC OUT TYPE 
GROUP (93) 5 
GUARDED PACKAGE 

PORT UNAFFECTED (93) 
IF POSTPONED (vgg) UNITS 
IMPURE (v93) PROCEDURE . 
IN PROCESS 
INERTIAL (v93) PURE (93) arfaare 
INOUT 
IS BANGE WAIT 

RECORD WHEN 
LABEL REGISTER re 
LIBRARY REJECT (v 93) WITH 
LINKAGE REM 
LITERAL (Vgg) REPORT XNOR (Va) 
LOOP RETURN XOR 

ROL (v 93) 


2.3.4 Größen 


Größen, im Englischen "literals", dienen zur Darstellung von Inhalten 
bestimmter Objekte oder fester Werte. Man unterscheidet hierbei zwi- 
schen numerischen Größen, einzelnen Zeichen ("character") und Zei- 
chenketten ("strings"), Aufzählgrößen ("enumeration types") und sog. 
"Bit-Strings". 
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2.3.4.1 Numerische Größen 


Numerische Größen können unterteilt werden in abstrakte, einheiten- 
lose numerische Größen zu Basen im Bereich von 2 bis 16 (Basis 10 ist 
die herkömmliche Darstellung) und mit Einheiten behaftete, sog. 
"physikalische" Größen. 


Abstrakte numerische Größen zur Basis 10 


Der einfachste Größentyp ist von ganzzahliger Art ("integer") mit ne- 
gativen oder positiven Werten. Erlaubt ist die Exponentialschreibweise 
mit nicht negativen, ganzzahligen Exponenten unter Einbeziehung 
von bedeutungslosen Unterstrichen (__ ). Diese Unterstriche dienen 
lediglich der besseren Lesbarkeit von besonders langen Zahlen. Nicht 
enthalten sein dürfen insbesondere Leerzeichen und Dezimalpunkte. 
Integerwerte können mit einer oder mehreren Nullen beginnen. Das 
Pluszeichen bei positiven Exponenten kann weggelassen werden. 


2 -- dies alles sind Beispiele von 
00124789673 -- Integergroessen, die in VHDL 
250_000_000 verwendet werden koennen; man 


3E6 beachte Exponentialschreibweise 
2_346e+3 -- und Unterstriche 

20.0 I!!! kein Integerwert: Dezimalpunkt 
3E-6 I!!! kein Integerwert: neg. Exponent 


Im Gegensatz zu den Integergrößen, die keinen Dezimalpunkt aufwei- 
sen dürfen, müssen Fließkommagrößen (reelle Größen) einen Dezimal- 
punkt enthalten. Außerdem können sie negative Exponenten besitzen. 


2.0012 dies sind Beispiele von reellen 
16.896E Groessen und ihre Darstellungs 
65.89E moeglichkeiten in VHDL; 


3_123.5e+6 auch hier gelten Exponential- 
23.4e-3 schreibweise und Unterstriche. 


234e-4 I!!! kein reeller Wert: . fehlt 
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Abstrakte numerische Größen zu von 10 verschiedenen Basen 


Bei diesen Typen muß die Basis (im Bereich von 2 bis 16) explizit an- 
gegeben werden: 


basis#integerwert[.integerwert]#[exponent] 


Die einzelnen Ziffernwerte müssen jeweils kleiner als die Basis sein. 
Für Zahlen größer als 9 gilt die hexadezimale Schreibweise: 


oder "A" entspricht der Basis 10, 
oder "B" entspricht der Basis 11, 
oder "C" entspricht der Basis 12, 
oder "D" entspricht der Basis 13, 
oder "E" entspricht der Basis 14, 
"£" oder "F" entspricht der Basis 15. 


Die Basis des Exponenten ist immer 10, unabhängig von der Basis. 


2#110_010 Beispiele von ganzahligen 
3#221_002_012# und reellen Groessen 


8#476#E9 mit von 10 verschiedener 


8#177_001 Basis. 


16#fff_abc# Die Basis wird durch das 

16#f9ac.O Nummernsymbol # abgehoben; 
16#ACE.2#e-2 der Exponent steht dahinter. 
17#ACG.2#e-2 ııı illegal: Basis > 16 

8#787_119 ıı! illegal: Ziffernwerte zu gross 


Physikalische Größen 


Physikalische Größen bestehen aus einem Wert in beliebiger Darstel- 
lung (siehe oben) und einer Einheit. Die erlaubten Einheiten werden 
in einer Typdeklaration festgelegt (siehe Abschnitt 3.2). Die meistbe- 
nutzte physikalische Größe ist die Zeit. Als Basiseinheit ist hier £s (= 
Femtosekunden, 1.0E-15 sec) üblich. Daneben sind sog. abgeleitete 
Einheiten (ps, ns, us, etc.) erlaubt. 


-- Beispiele von physikalischen 
Groessen (Wert und Einheit) 
hier: Zeitgroessen 
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2.3.4.2  Zeichengrößen 


Zeichengrößen, im Englischen "characters", sind einzelne Zeichen, die 
in Hochkommata stehen müssen. Sie sind allerdings case-sensitiv, d.h. 
ein 'a' undein 'A' werden in VHDL unterschieden. 


-- dies alles sind gueltige und 


verschiedene Zeichengroessen. 


2.3.4.3  Zeichenketten 


Zeichenketten, im Englischen "strings", sind beliebig lange Ketten aus 
Einzelzeichen, die in Anführungszeichen stehen. Es ist auch eine leere 
Zeichenkette erlaubt. Wie bei Einzelzeichen wird auch bei den 
Zeichenketten zwischen Groß- und Kleinschreibung unterschieden; 
d.h. die Zeichenketten "VHDL", "Vhdl" und "vhdl" sind von- 
einander verschieden. Zeichenketten innerhalb von Zeichenketten ste- 
hen in doppelten Anführungszeichen. Um Zeichenketten zu verknüp- 
fen (zusammenzubinden), ist der Verknüpfungsoperator (&) zu ver- 
wenden. 


Achtung: Eine Zeichenkette mit einem Element entspricht nicht dem 
dazu passenden Einzelzeichen, d.h. beispielsweise, daß die Zeichen- 
kette "A" ungleich dem Zeichen 'A' ist. 


"Dies ist eine Zeichenkette" in VHDL qgueltige 


"erster, " & "zweiter String" Zeichenketten 
"Alpha", "alpha" verschiedene Zeichenketten 


u" leere Zeichenkette 
Ein Anfuehrungszeichen: "" " -- Ein Anfuehrungszeichen: " 


Ein ""string"" in einem String" 


2.3.4.4  Bit-String-Größen 


Bit-Strings sind Zeichenketten, die aus den Ziffern 0 bis 9 und den 
Buchstaben a (A) bis £ (F), entsprechend dem hexadezimalen Zif- 
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fernsatz, bestehen und einen binären, oktalen oder hexadezimalen 
Wert darstellen. Ähnlich wie bei den numerischen Größen zu von 10 
verschiedenen Basen wird vor der in Anführungsstrichen stehenden 
Zeichenkette die Basis vermerkt: 


A der Buchstabe "b" oder "B" kennzeichnet binären Code; er kann 
auch weggelassen werden (Defaultwert), 


A der Buchstabe "o" oder "O0" kennzeichnet oktalen Code, 


A der Buchstabe "x" oder "x" kennzeichnet hexadezimalen Code. 


Der Wert der Ziffern in der Zeichenkette muß kleiner als die Basis 
sein. Bedeutungslose Unterstriche dürfen enthalten sein, falls die Basis 
explizit angegeben ist. 


"110010001000" gueltige Bit-Strings 
b&"110_010_001_000" -- fuer die Dezimalzahl 3208 


o"6210" -- in binaerem, oktalem und 
x"c88" -- hexadezimalem Code 


Bit-Strings dienen zur Kurzdarstellung von Werten des Typs bit_ 
vector. Bei der Darstellung in oktalem und hexadezimalem Code 
werden sie bei der Zuweisung entsprechend konvertiert. Der Bit-String 
x"Ofa" entspricht dem Bit-String b"0000_1111_1010". Führen- 
de Nullen werden also umgesetzt. 


Bit-Strings sind nach Yg7 nicht auf andere Typen anwendbar. Nach 
93 ist z.B. eine Zuweisung auch auf Objekte vom Typ einer mehr- 
wertigen Logik möglich. Es stehen dabei selbstverständlich nur die 
"starke 0" und die "starke 1" als Wert zur Verfügung, da nur für diese 
eine allgemeingültige Umwandlung zwischen den drei Basen bekannt 
ist. 


2.33 Trenn- und Begrenzungszeichen 


Um verschiedene lexikalische Elemente, die nacheinander aufgeführt 
sind, richtig als eigenständige Elemente interpretieren zu können, müs- 
sen zwischen ihnen Zeichen stehen, die die einzelnen lexikalischen 
Elemente abgrenzen oder trennen. 
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Als Trenn- und Begrenzungszeichen dienen sowohl Leerzeichen, die 
außerhalb von Kommentaren, Zeichen und Zeichenketten stehen, als 
auch Formatierungszeichen und folgende Operatoren, Klammern und 
Kommentarzeichen: 


Einzelzeichen: (Sag Mr Fe a a ea 
Zusammenge- 
setzte Zeichen: => >= <= ı= /= > **-- 


Die Verwendung von Leerzeichen und Zeilenumbrüchen ist, wenn ein 
Trennzeichen eingesetzt wird, nicht notwendig. Sie dienen dann nur 
der besseren Lesbarkeit des VHDL-Textes. Die Architektur struc- 
tural des Halbaddierers aus Teil A könnte deshalb - syntaktisch 
vollkommen korrekt - auch so aussehen: 


ARCHITECTURE structural OF halfadder IS COMPONENT xor2 
PORT (c1,c2:IN bit;c3:0OUT bit) ;END COMPONENT; COMPONENT--Hallo 


and2 PORT (c4,c5:IN bit;c6:0OUT bit) ;END COMPONENT; BEGIN 
xor_instance:xor2 PORT MAP (sum_a, sum_b, sum) ;and_instance 


:and2 PORT MAP (sum_a,sum_b,carry);END structural;--Leute! 


2.4 Sprachkonstrukte 


Unter Sprachkonstrukten sind sämtliche Kombinationen von lexikali- 
schen Elementen zu verstehen, die eine syntaktische Bedeutung be- 
sitzen. 


Es kann dabei grob zwischen Primitiven, Befehlen und syntaktischen 
Rahmen für Funktionen, Prozeduren, Design-Einheiten, etc. unter- 
schieden werden. 


2.4.1 Primitive 


Primitive stellen in irgendeinerweise einen Wert dar. Primitive sind 
entweder einzelne Operanden oder Ausdrücke, bestehend aus Operan- 
den und Operatoren. Das Ergebnis von zwei mit einem Operator ver- 
knüpften Operanden kann selbst wieder als Operand verwendet wer- 
den. Zu achten ist dabei jedoch auf Typkonformität. Einige Operato- 
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ren verlangen nach bestimmten Operandentypen, andere wiederum 
können verschiedene Operandentypen in unterschiedlicher Weise ver- 
arbeiten (sog. "überladene" Operatoren). 


2.4.1.1 Operanden 
Es gibt folgende Alternativen für Operanden: 


m) Explizite Größenangaben: numerische Größen, Zeichen und 
Zeichenketten sowie Bit-Strings; sie können direkt als Operan- 
den eingesetzt werden. 


m Bezeichner: Referenzname eines Objektes ("identifier"). 


71 Attribute: sie dienen zur Abfrage bestimmter Eigenschaften von 
Objekten. 


71 Aggregate: im Englischen "aggregates"; sie kombinieren einen 
oder mehrere Werte in einem Feldtyp ("array") oder zusammen- 
gesetzten Typ ("record"). 


m Qualifizierte Ausdrücke ("qualified expression"): sie dienen zur 
expliziten Festlegung des Datentyps bei Operanden, die mehre- 
ren Typen entsprechen Können. Die Syntax hierfür lautet: 


type_name' (ambiguous_operand_expr) 


I Funktionsaufrufe 


I Typumwandlungen 


Einige Beispiele für verschiedene Operanden bzw. Ausdrücke: 


= 3,5% 2,35 reelle Operanden 
300 + 500; -- ganzzahlige Operanden 


bb: 1005 -- Bezeichner (b) als Operand 
b'HIGH + q'LOW; -- Attribute (HIGH, LOW) 
= NOT bit_vector' ("001"); -- qualified expression 


2.4.1.2 Operatoren und Prioritäten 


Operatoren verknüpfen einen oder mehrere Operanden zu einem 
neuen Wert bzw. Operanden. Die verschiedenen Operatoren sind in 
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Gruppen mit gleicher Priorität eingeteilt. Die Priorität der Gruppen 
(entsprechend der nachfolgenden Aufzählung) regelt die Reihenfolge 
bei der Abarbeitung verketteter Operatoren. 


Die Priorität der Operatoren nimmt in folgender Aufzählung nach 
unten hin ab: 


I Diverse Operatoren (** ABS NOT) 

m) Multiplizierende Operatoren (* / MOD REM) 

I Signum-Operatoren (+ -) 

I Addierende Operatoren (+-&) 

I Vergleichsoperatoren = /= < <= > >=) 
I Logische Operatoren (AND NAND OR NOR XOR) 


(xNOR (nur /93)) 


Operatoren mit gleicher Priorität werden in der Reihenfolge des Auf- 
tretens im Quellcode abgearbeitet. Ist eine andere Ausführungsreihen- 
folge erwünscht, so muß dies durch Klammerung explizit gekenn- 
zeichnet werden. Dafür stehen nur runde Klammern zur Verfügung. 


ii En ee 
a AND (b OR c); d 0 
(a AND b) OR c; e = '1' 


x and y /= zZ; 
x and (y /= 2); entspricht u 
(x and y) /= zZ; entspricht nicht u 


Es sei hier bereits auf die Identität des Vergleichsoperators "<=" ("klei- 
ner gleich") mit dem Symbol für eine Signalzuweisung, z.B. "a <= 
32;" hingewiesen. Die korrekte Interpretation ergibt sich aus dem je- 
weiligen Umfeld, in dem dieses Symbol steht. 


2.4.2 Befehle 


Befehle sind Sequenzen von VHDL-Schlüsselwörtern, die eine be- 
stimmte Funktion besitzen. Befehle können, angefangen von einfa- 
chen Signalzuweisungen bis hin zu komplexeren Gebilden wie Schlei- 
fen oder Verzweigungen, sehr vielfältiger Art sein. Die Beschreibung 
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der einzelnen Befehle erfolgt detailliert in den entsprechenden Kapi- 
teln. Hier soll deshalb nur eine erste Unterteilung in die wichtigsten 
Befehlsklassen erfolgen: 


Deklarationen 


Hierbei handelt es sich im einzelnen um: 


Typdeklarationen, 
Objektdeklarationen, 
Schnittstellendeklarationen, 


Komponentendeklarationen, 


"112000 


Funktions- und Prozedurdeklarationen. 


Sequentielle Befehle 


Sequentielle, d.h. nacheinander ablaufende Befehle, finden sich nur 
innerhalb von sog. Prozessen, Funktionen oder Prozeduren. Es handelt 
sich dabei um programmiersprachenähnliche Befehle (Schleifen, Ver- 
zweigungen, Variablenzuweisungen, etc.). 


Nebenläufige Befehle 


Im Gegensatz zu vielen, rein sequentiellen Programmiersprachen 
kennt man in VHDL auch parallele oder nebenläufige Befehle, die das 
spezielle (parallelartige) Verhalten von Hardware (z.B. von parallel ge- 
schalteten Flip-Flops in Registern) widerspiegeln. 


Konfigurationsbefehle 


Eine besondere Klasse von Befehlen dient zum Konfigurieren von 
VHDL-Modellen in der entsprechenden Design-Einheit oder in struk- 
turalen Architekturen. 


2.4.3 Syntaktische Rahmen 


Hierbei handelt es sich um bestimmte Schlüsselwortkombinationen, die 
den syntaktischen Rahmen für Funktionen, Prozeduren, Design-Ein- 
heiten etc. bilden. Sie enthalten i.d.R. am Anfang das jeweilige Schlüs- 
selwort und den Referenznamen und am Schluß eine Anweisung mit 
dem Schlüsselwort END. 
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Sämtliche Daten in VHDL werden über sog. Objekte verwaltet. Jedes 
Objekt gehört einer bestimmten Objektklasse an und besitzt einen de- 
finierten Datentyp. Desweiteren benötigt jedes Objekt einen Referenz- 
namen, den sog. Bezeichner (im Englischen "identifier"). 


Vor der eigentlichen Verwendung in der Modellbeschreibung muß das 
Objekt daher zunächst unter Angabe der Objektklasse, des Identifiers, 
des Datentyps und eventuell eines Defaultwertes deklariert werden. 


Zur Festlegung eines Datentyps werden vor der Objektdeklaration ge- 
trennte Typdeklarationen verwendet. 


3.1 Objektklassen 


Konstanten 


Konstanten sind Objekte, deren Wert nur einmal zugewiesen werden 
kann. Der Wert bleibt somit über der Zeit, d.h. während der gesamten 
Simulationsdauer, konstant. 


Variablen 


Variablen sind Objekte, deren aktueller Wert gelesen und neu zugewie- 
sen werden kann. Der Variablenwert kann sich also im Laufe der 
Simulation ändern. Beim Lesen der Variable ist allerdings immer nur 
der aktuelle Wert verfügbar, auf vergangene Werte kann nicht zurück- 
gegriffen werden. 


Signale 


Signale können wie Variablen jederzeit gelesen und neu zugewiesen 
werden; ihr Wert besitzt also ebenfalls einen zeitlich veränderlichen 
Verlauf. Im Gegensatz zu Variablen wird bei Signalen allerdings die- 
ser zeitliche Verlauf gespeichert, so daß auch auf Werte in der Ver- 
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gangenheit zugegriffen werden kann. Außerdem ist es möglich, für 
Signale einen Wert in der Zukunft vorzusehen. Beispielsweise weist der 
Befehl "a <= '0' AFTER 10 ns;" dem Signal a den Wert 
'0' in 1O ns, vom momentanen Zeitpunkt ab gerechnet, zu. 


Dateien 


Dateien enthalten Folgen von Werten, die über bestimmte File-V/O- 
Funktionen zu einem bestimmten Zeitpunkt oder zeitverteilt gelesen 
oder geschrieben werden können. 


3.2 Datentypen und Typdeklarationen 


Bevor in einem VHDL-Modell mit Objekten gearbeitet werden Kann, 
muß festgelegt werden, welche Werte das Objekt annehmen kann (z.B. 
"Signal a kann einen ganzzahligen Wert zwischen O und 10 besitzen"). 
Für diesen Zweck werden Datentypen eingesetzt, mit deren Hilfe die 
Wertebereiche definiert werden. Die Sprache VHDL besitzt einerseits 
nur sehr wenige, vorab definierte Datentypen, wie real oder inte- 
ger. Andererseits bietet sie aber umfangreiche Möglichkeiten, benut- 
zerdefinierte Datentypen zu definieren. Im nachstehenden Beispiel 
wird über den Datentyp augenzahl festgelegt, daß der Variablen 
wuerfel nur ganzzahlige Werte zwischen 1 und 6 zugewiesen wer- 
den können. 


Bei der Normierung von VHDL wurde eine strenge Typisierung der 
Daten angestrebt, weil dadurch "Programmierfehler" oft schneller de- 
tektiert werden. Bei jeder Operation, die auf ein Objekt angewandt 
wird, wird überprüft, ob der Datentyp des Objekts von der jeweiligen 
Operation auch bearbeitet werden kann. 


72 © G. Lehmann/B. Wunder/M. Selz 


3 Objekte 


-- "real-Variable" 


-- "integer-Variable" 


-- !!! Fehler; der vordefinierte Operator > 
-- gilt nur fuer gleiche Datentypen! 


Der VHDL-Anwender hat die Möglichkeit, den Anwendungsbereich 
der vordefinierten Operatoren so zu erweitern, daß auch die benutzer- 
eigenen Datentypen verarbeitet werden können (sog. "Overloading"). 


Üblicherweise werden Datentypen in skalare, Feld- und zusammenge- 
setzte sowie sonstige Typen unterteilt. Letztere sind File- und Access- 
Typen. Diese Typen sind zur Erläuterung der grundlegenden VHDL- 
Konstrukte nicht notwendig. Sie werden deshalb erst am Ende von Teil 
B behandelt. 


Typdeklarationen können an folgenden Stellen auftreten: 
im ENTITY-Deklarationsteil, 

im ARCHITECTURE-Deklarationsteil, 

im PACKAGE, 

im PACKAGE BODY, 

im BLOCK-Deklarationsteil, 

im PROCESS-Deklarationsteil, 

im FUNCTION- und PROCEDURE-Deklarationsteil. 


Jn0o000 00 


3.2.1 Einfache Typen 
3.2.1.1  Aufzähltypen 


Objekte dieses Typs, im Englischen "enumeration type" genannt, kön- 
nen nur bestimmte Werte annehmen. Die endliche Anzahl von mögli- 
chen Werten wird in der Typdeklaration festgelegt: 


TYPE enum_type_name IS ( value_l { , value_n }); 


Die möglichen Werte (value_l1 {, value_n}) müssen Bezeich- 
ner sein. Für die Bezeichner gelten die oben definierten Anforderun- 
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gen. Alternativ dazu können Einzelzeichen (character) in einfa- 
chen Hochkommata als Werte eines Aufzähltyps eingesetzt werden. 


E zustand IS (init, run, stop); -- Bezeichner 

E 1log3 SO, BU FZENE -- Einzelzeichen (Char.) 
E fehler IS (0, 1, 2); -- !! illegal: Bezeichner 
-- 0 und 1 ungueltig 


Folgende Aufzähltypen sind im Package standard vordefiniert und 
können in jedem VHDL-Modell eingesetzt werden: 


YPE boolean (false, true); 

YPE bit FOLIEN) 

YPE character BET -- VHDL'87: 128 Zeichen 
-- VHDL'93: 256 Zeichen 

IYPE severity_level (note, warning, error, failure); 


Die Bezeichner eines Aufzähltyps werden implizit mit ganzzahligen 
Werten von links nach rechts durchnumeriert. Das am weitesten links 
stehende Element nimmt die Position 0 ein. Beispielsweise hat das 
Element run des Typs zustand die Positionsnummer 1. Auf die 
Positionsnummern kann mit Hilfe von Attributen zugegriffen werden. 


3.2.1.2  Ganzzahlige Typen 


Ganzzahlige Typen, im Englischen "integer types", werden durch di- 
rekte Angabe einer ganzzahligen Ober- und Untergrenze des mögli- 
chen Wertebereiches deklariert. Alternativ dazu kann der Wertebereich 
auch von einem anderen Typ abgeleitet werden: 


TYPE int_type_name IS RANGE range_low 
TO range_high; 


TYPE int_type_name IS RANGE range_high 
DOWNTO range_low; 


TYPE int_type_name IS RANGE 
other_int_type_name'RANGE; 
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Der maximal mögliche Wertebereich für einen ganzzahligen Typ ist 
abhängig von der jeweiligen Rechnerumgebung. Die VHDL-Norm 
definiert jedoch, daß der mögliche Wertebereich mindestens von 
-2147483647 bis +2147483647 reicht. VHDL weicht damit von 
gängigen Programmiersprachen ab, die für ganzzahlige Werte einen 
Bereich von -2147483648 bis +2147483647 definieren. 


3.2.1.3  Fließkommatypen 


Entsprechend den ganzzahligen Typen werden auch Fließkomma- 
typen, im Englischen "floating point types" oder "real types", dekla- 
riert. Der einzige Unterschied sind die Ober- und Untergrenze des Be- 
reichs. Diese Grenzen müssen hier Fließkommawerte sein: 


TYPE real_type_name IS RANGE range_low 
TO range_high; 


TYPE real_type_name IS RANGE range_high 
DOWNTO range_low; 


TYPE real_type_name IS RANGE 
other_real_type_name 'RANGE; 


Auch bei den Fließkommatypen ist der Zahlenbereich von der Rech- 
nerumgebung abhängig. Die VHDL-Norm definiert einen Mindestbe- 
reich von -1.0E38 bis +1.0E38. 


Auf der beigefügten Diskette befindet sich im File mit Namen "TYP _ 
ATTR.VHD" ein VHDL-Modell, mit dem Sie den tatsächlichen Zah- 
lenbereich Ihrer Rechnerumgebung bestimmen können. 


E neg_zweistellige IS RANGE -99 TO -10; ine, >99 10 

E stack_position IS RANGE 9 DOWNTO 0; Ines ed 
stp IS RANGE stack_position'RANGE; int. 9-0 

E scale IS RANGE -1.0 TO 1.0; Fliesskomma 

not_valid IS RANGE -1.0 TO 1; It! illegal 
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Die beiden Typen integer und real können ohne Deklaration 
verwendet werden, sie sind folgendermaßen vordeklariert: 


IYPE integer Br -- systemabhängig 


YPE real Ei -- systemabhängig 


3.2.1.4 Physikalische Typen 


Physikalische Werte bestehen aus einem ganzzahligen oder reellen 
Zahlenwert und einer Einheit. Neben einer sog. Basis-Einheit können 
in der Deklaration eines physikalischen Typs weitere, von vorherge- 
henden Einheiten abgeleitete Einheiten angegeben werden: 


TYPE phys_type_name IS RANGE range_low 


TO range_high 
UNITS 
base_unit; 
{ derived_unit = multiplicator unit; } 
END UNITS; 


Die Werte von range_low, range_high undmultiplicator 
müssen ganzzahlig sein. Alle physikalischen Objekte können mit reel- 
len Werten versehen werden, werden jedoch auf ein ganzzahliges Viel- 
faches der Basiseinheit gerundet. 


Im folgenden ist ein Beispiel eines benutzerdefinierten, physikalischen 
Typs gezeigt: 


E length IS RANGE E -1000 bis +1000 km 
UNITS mm; Basiseinheit mm; 
= 10 mm; abgeleitet 

1000; Einheiten 

10 dm; 


1E3 m; 

inch 25 mm; nur ganzzahlige 
foot 305 mm; Multiplikatoren! 
mile 16093 dm; Landmeile 


END UNITS; 
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Der einzige vordefinierte, physikalische Typ ist time: 


E time IS RANGE ... systemabhaengiger Bereich 
UNITS £s; -- Basiseinheit: fs 
= 1000 3 sukzessiv 

1000 ; abgeleitete 

1000 2 Einheiten 


1000 ; bis hin 


1000 R zu: 
60 Minute und 
60 Stunde 
END UNITS; 


3.2.1.5  Abgeleitete einfache Typen 


Man kann von bereits deklarierten Typen weitere Typen, sog. Unter- 
typen (im Englischen "subtypes"), ableiten. Untertypen sind im Falle 
einfacher Typen im Wertebereich eingeschränkte Basistypen. Die 
Ableitung eines Untertyps von einem Untertyp ist nicht möglich. 


Die Syntax einer einfachen Untertyp-Deklaration mit Einschränkung 
im Wertebereich lautet wie folgt: 


SUBTYPE subtype_name IS base_type_name 
[RANGE range_low TO range_high]; 


SUBTYPE subtype_name IS base_type_name 
[RANGE range_high DOWNTO range_low]; 


Die Verwendung von abgeleiteten Typen oder Untertypen hat fol- 
gende Vorteile: 


I Durch die meist kürzere Untertypdefinition kann VHDL-Code 
und Zeit eingespart werden. 


I Durch die Einschränkung des zulässigen Wertebereiches eines 
VHDL-Objektes können Modellierungsfehler leichter entdeckt 
werden. 


I Objekte mit verschiedenen Untertypen des gleichen Basistyps 
können mit den Operatoren des Basistyps verknüpft werden. Bei 
verschiedenen Typen ist dies i.d.R. nicht möglich. 
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Das nachstehende Beispiel illustriert den letztgenannten Vorteil: 


ESS 
YPE addressl IS RANGE 0 TO 63; -- neue 
E address2 IS RANGE 0 TO 127; -- int.-Typen 
E addli IS integer RANGE 0 TO 63; -- abgeleitete 
E add2 IS integer RANGE 0 TO 127; -- int.-Typen 
BE ta : addressl; VARIABLE tb, tc : address2; 

sa : addl; VARIABLE sb, sc : add2; 


+ sb; -- legal: gleicher Basistyp 
+ tb; -- !!! illegal: verschiedene Typen 


END PROCESS; 


Unter Verwendung des Attributes HIGH vordefinierte Untertypen 
sind: 


E natural IS integer RANGE 0 TO integer'HIGH; 
E positive IS integer RANGE 1 TO integer'HIGH; 
E delay_length IS time RANGE 0 fs TO time'HIGH; 
delay_length nur in VHDL'93 vordefiniert! 


Hinweis: Eine syntaktisch entsprechende Einschränkung des Wertebe- 
reiches kann auch erst in der Objektdeklaration erfolgen. 


3.2.1.6  Typumwandlungen 


VHDL bietet die Möglichkeit der Umwandlung zwischen verschie- 
denen Typen. Ein Anwendungsfall für solche Funktionen ist die Zu- 
sammenschaltung von verschiedenen VHDL-Modellen mit unter- 
schiedlichen logischen Signaltypen. Hier müssen bei der Verdrahtung 
Funktionen zur Signalkonvertierung angegeben werden. 


Implizit sind in VHDL Funktionen zur Umwandlung von Fließkom- 
matypen in ganzzahlige Typen und umgekehrt, sowie zwischen ver- 
schiedenen ganzzahligen Typen und zwischen verschiedenen Fließ- 
kommatypen bekannt: 
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integer (float_object_name) 
real (integer_object_name) 


int_type_name (other_int_type_obj_name) 
float_type_name (other_float_type_obj_name) 


Bei der Wandlung zu ganzzahligen Werten wird der Fließkommawert 
gerundet (bis ausschließlich .5 abgerundet, ab .5 aufgerundet). Der 
Wertebereich des Zieltyps darf bei der Typumwandlung nicht über- 
schritten werden. 


-- Variable ganzzahligen Typs 
-- Fließkommavariable 


+ integer (vb); -- legal, va = 6 
+ vb; -- !!! illegal: versch. Typen 


Funktionen zur Umwandlung zwischen verschiedenen Logiktypen 
müssen selbst definiert werden. 


3.2.2 Feldtypen 


Sollen mehrere Werte in einem Objekt zusammengefaßt werden (z.B. 
die Werte einer Matrix), dann wird für dieses Objekt ein sog. Feldtyp 
("array type") verwendet. Im eindimensionalen Fall nennt man die Fel- 
der "Vektoren", im zweidimensionalen Fall "Matrizen". Die Einzelele- 
mente von Feldern können neben skalaren Typen auch andere Feld- 
typen oder zusammengesetzte Typen sein, müssen aber innerhalb des 
Feldes von ein- und demselben Typ sein. 


Man unterscheidet bei Feldern zwischen Feldern mit unbeschränkter 
Größe ("unconstrained arrays") und eingeschränkter Größe ("constrai- 
ned arrays"). 
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3.2.2.1 Vektoren 


Die Typdeklaration eines Feldes hat im eindimensionalen Fall folgen- 
des Aussehen: 


TYPE array_type_name IS ARRAY 
(index_type RANGE <>) OF base_type_name; 


TYPE array_type_name IS ARRAY 
([index_type RANGE] range_low TO range_high) 
OF base_type_name; 


TYPE array_type_name IS ARRAY 
([index_type RANGE] range_high 
DOWNTO range_low) 
OF base_type_name; 


Das Konstrukt RANGE <> bedeutet dabei unbeschränkte Länge des 
Vektors (im Rahmen des möglichen Bereiches des Index-Typs). 


Als Index (index_type) können beliebige diskrete Typen, also ne- 
ben ganzzahligen Typen auch Aufzähltypen, verwendet werden. Der 
Typ des Index bestimmt auch die Default-Indizierung. Bei einge- 
schränkter Indizierung und eindeutigem Typ ist die Angabe des 
Schlüsselwortes RANGE und des Index-Typs nicht unbedingt erforder- 
lich. 


BE color IS (yellow, red, green, blue); 
BE int_vecl IS ARRAY (color RANGE <>) 
OF integer; 


int_vec2 IS ARRAY (red TO blue) 
OF integer; Vektorlaenge: 3 
E int_vec3 IS ARRAY (255 DOWNTO 0) 


OF integer; Vektorlaenge: 256 


Die Vektortypen string und bit_vector müssen nicht deklariert 
werden; sie sind bereits im Package standard enthalten. Bit-Vek- 
toren eignen sich beispielsweise zur Beschreibung von Bussen, Regi- 
stern oder Zeilen einer PLA-Matrix. 


80 © G. Lehmann/B. Wunder/M. Selz 


3 Objekte 


E string IS ARRAY (positive RANGE <>) 
OF character; vordefinierter T 
E bit_vector IS ARRAY (natural RANGE <>) 
OE-DEEE vordefinierter T 


3.2.2.2  Mehrdimensionale Felder 


Im mehrdimensionalen Fall (allgemeine Felder) muß entsprechend 
der Vektordeklaration für jede Dimension der Indextyp und der In- 
dexbereich angegeben werden. Ein Vermischen der drei verschiede- 
nen Indizierungsarten (unbeschränkt, beschränkt mit aufsteigender In- 
dizierung, beschränkt mit abfallender Indizierung) ist in einem mehr- 
dimensionalen Feld erlaubt. Die Typdeklaration lautet wie folgt: 


TYPE array_type_name IS ARRAY 
( index_type RANGE <> 
{ , further_index } ) OF base_type_nanme; 


TYPE array_type_name IS ARRAY 
([lindex_type RANGE] range_low TO range_high 
{ , further_index } ) OF base_type_nanme; 


TYPE array_type_name IS ARRAY 
([lindex_type RANGE] range_high 
DOWNTO range_low 
{ , further_index } ) OF base_type_nanme; 


Der Basistyp des Feldes kann dabei auch wieder ein Feld sein. 


BE int_matrix IS ARRAY -- 3x6 Matrix 
(integer RANGE 1 TO 3, 
integer RANGE 1 TO 6) OF integer; 
E real_array IS ARRAY -- dreidimensionales Feld 
(integer RANGE 8 DOWNTO 1, 
color RANGE <>, 
color RANGE red TO blue) OF real; 
array_of_array IS ARRAY -- Vektor mit Vektorelementen 
(color RANGE red TO blue) OF int_vec3; 


Di 
Di 


© G. Lehmann/B. Wunder/M. Selz 81 


B Die Sprache VHDL 


3.2.2.3  Abgeleitete Feldtypen 


Wie von den einfachen Typen können auch von den Feldtypen Unter- 
typen abgeleitet werden. Im Unterschied zu einfachen Typen wird bei 
Feldtypen nicht der Wertebereich, sondern der Indexbereich einge- 
schränkt. Mehrfache Untertypableitungen sind auch hier nicht mög- 
lich. 


Die Syntax einer Untertyp-Deklaration von im allgemeinen mehrdi- 
mensionalen Feldtypen lautet folgendermaßen: 


SUBTYPE subtype_name IS base_type_name 
( range_low TO range_high 
{ , further_index_constraints } ); 


SUBTYPE subtype_name IS base_type_name 
( range_high DOWNTO range_low 
{ , further_index_constraints } ); 


E bit_matrix IS ARRAY (1 TO 256, 1 TO 256) OF bit; 

YPE nachname IS string (1 TO 20); -- 20 Zeichen 
YPE word 18 bit_vector {1 TO 16). — 16 Bit 

YPE eight_word IS bit_matrix (1 TO 16, 1 TO 8); 

TYPE byte LS word: 11 TO:8%; -- !! illegal !! 


Hinweis: Eine syntaktisch entsprechende Einschränkung des Indexbe- 
reiches kann auch erst bei der Objektdeklaration erfolgen. 


3.2.3 Zusammengesetzte Typen 


Will man mehrere Elemente unterschiedlichen Typs in einem Objekt 
kombinieren, so verwendet man zusammengesetzte Typen, im Engli- 
schen "records": 


TYPE record_type_name IS RECORD 

record_element_l_name : element_l1_type ; 
{ record_element_n_name : element_n_type ;} 
END RECORD ; 
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Mit 7/93 kann der Name des zusammengesetzten Typs in der END- 
Anweisung wiederholt werden. Damit wird eine Vereinheitlichung der 
Rahmensyntax für Design-Einheiten und Befehle realisiert. 


TYPE record_type_name IS RECORD 


END RECORD [record_type_name] ; 


Zwei Beispiele für Records sind die folgenden Typen für Datum und 
komplexe Zahlen. 


YPE months IS (january, february, march, ... , december); 
SUBTYPE days IS integer RANGE 1 TO 31; 
YPE date IS RECORD 


year : natural; 
month : months; 
day ı days; 


END RECORD; 


E complex IS RECORD 
real_part : real; 
imag_part : real; 


Records selbst können wiederum Elemente eines Records sein. Man 
kann die Elemente eines Objekts mit zusammengesetztem Typ sowohl 
einzeln lesen als auch einzeln schreiben. 


3.3 _Objektdeklarationen 


Bevor ein Objekt, beispielsweise eine Variable delay_1lh, in einem 
VHDL-Modell verwendet werden kann, muß es deklariert werden, z.B.: 
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Die Deklaration von Objekten enthält also Elemente, die 


I das zu deklarierende Objekt einer Objektklasse zuordnen (hier: 
VARIABLE), 


a den Referenznamen des Objektes festlegen (hier: delay_1lh), 


I den Datentyp durch Angabe seines Referenznamens festlegen 
(hier: time), 


I gegebenenfalls einen Defaultwert für das Objekt angeben (hier: 
3 ns). 


Mehrere, gleichartige Objekte können in einer Anweisung gemeinsam 
deklariert werden. Als Datentyp können deklarierte Typen und Unter- 
typen übernommen oder spezielle Einschränkungen (entsprechend 
der Untertyp-Deklaration) vorgenommen werden. 


3.3.1 Konstanten 


Konstanten sind Objekte mit einem festem Wert, der sich im Laufe der 
Ausführung eines Modells nicht ändern kann. Dieser Wert muß in der 
Konstantendeklaration festgelegt werden, d.h. die Defaultwertvergabe 
ist hier obligatorisch. Der Typ von value muß dem Typ der Kon- 
stante entsprechen. Die Syntax der Konstantendeklaration ist wie folgt: 


CONSTANT const_name_l { ,„ const_name_ln } 
type_name := value ; 


ANT delay_lh : time := 12.5 ps; 


ANT x1, x2, x3: integer ı= 5; 

TANT r_address : bit_vector := b"1001_1110"; -- 0 TO 7 
ANT offset : bit_vector (1 TO 3) := "101"; 

ANT message : string := "Segmentation fault"; 


Konstantendeklarationen dürfen an folgenden Stellen stehen: 
A im ENTITY-Deklarationsteil, 

A im ARCHITECTURE-Deklarationsteil, 

A im PACKAGE, 

A im PACKAGE BODY, 
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im BLOCK-Deklarationsteil, 
im PROCESS-Deklarationsteil, 
im FUNCTION- und PROCEDURE-Deklarationsteil, 


in der Parameterliste von FUNCTION und PROCEDURE (nur 
Mode IN). 
Im Package darf die Konstantendeklaration als einzige Ausnahme 


ohne Wertangabe stehen (sog. "deferred constant"). Der Wert wird in 
einer entsprechenden Anweisung im Package Body festgelegt. 


J"o00u0n 


3.3.2 Variablen 


Variablen sind Objekte mit zeitlich veränderbaren Werten. In der ur- 
sprünglichen Norm (87) waren sie nur innerhalb eines einzigen Pro- 
zesses oder Unterprogramms (Funktion, Prozedur) gültig, um determi- 
nistisches Verhalten der VHDL-Modelle sicherzustellen. 


Bei einigen Anwendungsfällen, z.B. bei der Systemmodellierung oder 
der Verwaltung von Zuständen in objektorientierten Modellen, wird 
dies jedoch als Nachteil empfunden. Das strikte Verbot von globalen 
Variablen wurde deshalb nach langanhaltender Diskussion in der 
überarbeiteten Norm (93) aufgegeben. Nunmehr sind Variablen 
(nach besonderer Deklaration) auch von mehreren Prozessen inner- 
halb des Gültigkeitsbereiches quasi gleichzeitig les- und schreibbar. 
Der weniger gefährlich klingende Name "shared variable" ändert 
nichts an der Tatsache, daß damit Modelle erzeugt werden können, de- 
ren Verhalten nicht vorhersagbar ist (nichtdeterministische Modelle). 
Deshalb sollten VHDL-Anwender diese neue Möglichkeit nur mit 
Vorsicht verwenden. Momentan beschäftigt sich eine eigene VHDL- 
Arbeitsgruppe ausschließlich mit dem Konzept der globalen Variab- 
len. 


Die Syntax der Variablendeklaration sieht in der Norm Yg7 wie folgt 
aus: 


VARIABLE var_name_l { ,„ var_name_n } 
type_name [ := def_value ]; 


Die Angabe eines Defaultwertes ( def_value ) ist optional. Er darf 
ein beliebiger typkonformer Ausdruck sein und legt den initialen Wert 
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der Variablen fest. Ohne explizite Angabe eines Defaultwertes wird der 
Variablen zu Beginn der Simulation der Wert zugewiesen, der in der 
entsprechenden Typdeklaration am weitesten links steht. Der Default- 
wert für Variablen vom Typ bit istalso '0'. 


Enl, n2 ı natural; -- default: 0 
‚E v_addr : integer RANGE -10 TO 10; -- default: -10 
‚E o_thresh : real := 1.4; -- default: 1.4 


Die Deklarationen von Variablen können in Yg7 nur an folgenden 
Stellen stehen: 


A im PROCESS-Deklarationsteil, 
A im FUNCTION- und PROCEDURE-Deklarationsteil. 


Die in 7/93 um das optionale Wort SHARED erweiterte Syntax lautet: 


[SHARED] VARIABLE var_name_l { ,„ var_name_n } 
type_name [ := def_value ]; 


Ohne das Wort SHARED entspricht die Verwendung dem Standard 
von Vg7. Wird das Wort SHARED verwendet, darf die Deklaration nun 
in allen Deklarationsteilen mit Ausnahme von Prozessen und Unter- 
programmen eingesetzt werden. Diese Art von Variablen darf in Zo- 
nen des Modells gelesen und geschrieben werden, in der auch normale 
Variablen gelesen und geschrieben werden können, also in Prozessen 
und Unterprogrammen. 


3.3.3 Signale 


Neben den Variablen und Konstanten, die auch von prozeduralen Pro- 
grammiersprachen bekannt sind, verfügt VHDL noch über Objekte 
der Klasse "Signal". Diese wurde eingeführt, um die Eigenschaften 
elektronischer Systeme modellieren zu können. Änderungen von Si- 
gnalwerten können beispielsweise zeitverzögert zugewiesen werden. 
Damit lassen sich die Laufzeiten von Hardware-Komponenten nach- 
bilden. Signale dienen im wesentlichen dazu, Daten zwischen parallel 
arbeitenden Modulen auszutauschen. Verschiedene Module können 
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dabei mitunter auf ein- und dasselbe Signal schreiben. Diese Ei- 
genschaft gestattet die Modellierung von Busleitungen mit VHDL. 


Die Syntax der Signaldeklaration lautet wie folgt: 


SIGNAL sig_name_l { ,„ sig_name_n } 


type_name [ := def_value 


l; 


Der Ausdruck def_value ist hier ebenfalls ein optionaler typkon- 
former Ausdruck, der den initialen Wert des Signals festlegt (siehe Va- 
riablendeklaration). 


Signaldeklarationen dürfen an folgenden Stellen der Design-Einheiten 
stehen: 


7 im ENTITY-Deklarationsteil, 

m) im ARCHITECTURE-Deklarationsteil, 
71 im PACKAGE, 

A im BLOCK-Deklarationsteil. 


-- default: 

-- default: false 

-- default: '0' 
1; —- default: 1 


: boolean := true 
BI : boolean; 
SIGNAL sl, s2 : bit; 


SIGNAL d_value : integer RANGE 0 TO 1023 := 


true; 


SIGNAL flag_1 
SIGNAL flag_2 


3.3.4 Aliase 

Um ein Objekt oder einen Teil eines Objektes mit einem anderen Na- 
men und einem anderen Untertyp (z.B. inverse Indizierung) anspre- 
chen zu können, gibt es die Möglichkeit von Aliasen, deren Deklara- 
tion nachstehende Syntax besitzt: 


ALIAS alias_name alias_type IS 


aliased_object; 


SIGNAL 
LIAS 


bus_16 TO 15); 


DOWNTO 0) 


: bit_vector 
bl6 : bit_vector IS bus_16; 


LIAS 


bus_low : bit_vector 
bus_high : bit_vector 


LIAS 
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IS bus_16 (0 1 
IS bus_16 (8 1 


TO 7); 
9 15) 


87 


B Die Sprache VHDL 


Mit der Überarbeitung der Norm wurde der Einsatzbereich für Aliase 
erweitert. Nun können auch Typen und Unterprogramme mit Aliasen 
versehen werden. Die erweiterte Syntax in V’gg lautet: 


ALIAS alias_name [ : alias_type] 
IS aliased_object; 


ALIAS alias_name IS aliased_type; 


ALIAS alias_name IS aliased_subprogram 
[larg_l_type {, arg_n_type }] 
[RETURN result_type]l]; 


Die Angabe des Alias-Typs ist bei Objekten in der neuen Norm optio- 
nal. Die fett gedruckten, eckigen Klammern sind Teil der Alias-Dekla- 
rationssyntax. Einige Beispiele für die neue Norm (993): 


bus_low IS bus_16 (0 TO 7); -- Kurzform 
chars IS VEN E23 TA EST) -- in my_pack 


one2five IS work.my_pack.chars; -- Typ-Alias 
und IS "AND" [bit, bit RETURN bit]; -- Fkt.-Alias 


3.3.5 Implizite Deklaration 


Einen Sonderfall bei den Deklarationen bilden die ganzzahligen Lauf- 
variablen in FOR-Schleifenkonstrukten (FOR...LOOP und FOR... 
GENERATE). Diese müssen nicht explizit deklariert werden. 


3.3.6 Weitere Deklarationen 


Neben den erwähnten Objektklassen gibt es in VHDL noch einige wei- 
tere Elemente, die vor ihrer Verwendung deklariert werden müssen: 


I Unterprogramme (Funktionen und Prozeduren), 


A Schnittstellen von VHDL-Modellen, d.h. die Schnittstellensi- 
gnale (PORT) und Parameter (GENERIC) eines Modells, 


I Ein- und Ausgabeargumente von Unterprogrammen, 


I Komponenten. 
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3.4 Ansprechen von Objekten 
3.4.1 Objekte mit einfachem Typ 


VHDL-Objekte (Konstanten, Variablen und Signale), die einen einfa- 
chen Datentyp haben, werden durch ihren Namen referenziert: 


PROCESS 
CONSTANT tpd_default : time := A ns; 
VARIABLE delay_lh : time; 
VARIABLE distance : length; -- Typ length von oben 
EGIN 
distance := 5 inch + 3 cm; -- distance = 155 mm 
delay_lh := tpd_default; -- Zuweisung ueber Referenz- 
-- namen; delay_lh = A ns 


END PROCESS; 


3.4.2 Objekte mit Feldtyp 


Um Einzelelemente von Feldern anzusprechen, muß neben dem Refe- 
renznamen des Feldes auch die Position des bzw. der Einzelelemente 
mit angegeben werden. Dies kann auf unterschiedliche Art und Weise 
erfolgen. 


Indexed Names 


Das direkte Ansprechen von Feldelementen geschieht über entspre- 
chende Ausdrücke, die dem Referenznamen in runden Klammern 
nachgestellt werden. Die Anzahl der Ausdrücke muß mit der Dimen- 
sion des Feldes übereinstimmen: 


array_name ( index_l_type_expression 
{ , index_n_type_expression } |) 
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Ein Beispiel zur Verwendung von "indexed names": 


ECTURE arch_types OF types IS 
YPE vector IS ARRAY (positive RANGE <>) OF bit; 
YPE matrix IS ARRAY 

(positive RANGE <>, positive RANGE <>) OF bit; 
CONSTANT cl: vector (1 TO 4) := "1001"; 
CONSTANT c2: matrix (1 TO 3, 1 TO 3) 


20075,80L08,.#1129), 5 
EGIN 
PROCESS 
VARIABLE v_1l, v_2, v_4 : kit; 

VARIABLE v_3 : array_of_array; Dekl. siehe oben 
BEGIN 
v_1l := cl (3); Vektorelement, v_1 'o' 
w.2 = £2 (1527; Matrixelement, v_2 = '0' 

v4 :=c2 (1); ııı illegal 

v_3 (red) (234) := 1024; -- Element aus array_of_array 

v_3 (red) := (1,4,3,0,1,...); hier eindimens. An 
-- sprechen erlaubt 


END PROCESS; 
END arch_types; 


Sliced Names 


Um mehrere Einzelelemente eines eindimensionalen Feldes (Vektors) 
gleichzeitig anzusprechen, kann man zusammenhängende Elemente 
durch Angabe des diskreten Bereichs innerhalb des Vektors sozusagen 
"herausschneiden". Im Englischen spricht man von einem "slice": 


vector_name (slice_low TO slice_high) 
vector_name (slice_high DOWNTO slice_low) 


Die Bereichsgrenzen müssen dabei dem Indextyp des Vektors entspre- 
chen und im deklarierten Bereich liegen. Entspricht die Bereichs- 
definition nicht der bei der Deklaration angegebenen Zählrichtung 
(TO, DOWNTO) oder ist die Länge des Bereiches Null, so spricht man 
von einem "null slice". 
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ROCESS 
VARIABLE v_1, v_2 : bit_vector (0 TO 3) := "1111"; 
CONSTANT c_1 : bit_vectör ;= b"1001_0111"# — 0 TO 7 


TO 5); == y_L = "OL0T" 
[oO 8); -- !ıtı illegal: Index 8 zu gross 


END PROCI 


Aggregate 


Um mehrere, nicht unbedingt zusammenhängende Elemente eines 
Feldes mit einem Ausdruck zuzuweisen, bedient man sich eines sog. 
Aggregats (im Englischen "aggregate"). 


Durch Kommata getrennt werden Elementzuweisungen in einer run- 
den Klammer aneinandergereiht, die entweder Einzelelementzuweisun- 
gen oder Zuweisungen über einen zusammenhängenden Bereich sind. 
Außerdem kann durch das Schlüsselwort OTHERS allen noch nicht 
zugewiesenen Elementen ein Wert gegeben werden. Man unterscheidet 
die Zuweisung durch Position ("positional association") und die Zu- 
weisung durch explizites Zuordnen ("named association"). 


Bei der "positional association'' korrespondieren das Ziel der Zuwei- 
sung und das Element im Aggregat durch ihre Position. Die Zuwei- 
sung kann nur erfolgen, wenn im Aggregat alle vorhergehenden Ele- 
mente aufgeführt worden sind. 


" 


Alternativ dazu kann mit dem Zuweisungszeichen "=>" ein Element 
direkt angesprochen werden. Man spricht von "named association". 
Mit dem Zeichen "|" können mehrere Elementzuweisungen zusam- 
mengefaßt werden: 


[ elements_1 { | elements_n } =>] 
element_value 


Es gibt folgende Möglichkeiten der Elementauswahl (elements) in 
Aggregaten: 


I single_element 


m) range_low TO range_high 
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m 
I 


Eine Mischung von "positional" und "named association" ist nicht 
möglich (Ausnahme: OTHERS). Die mit dem Schlüsselwort OTHERS 
beginnende Elementzuweisung kann nur an letzter Stelle innerhalb 
des Aggregats stehen. 


range_high DOWNTO range_low 
OTHERS 


Bei mehrdimensionalen Feldern kann jeweils nur die erste Dimension 
mit einem Aggregat belegt werden. Auf der rechten Seite des Zuwei- 
sungspfeiles stehen dann Werte von (n-1)-dimensionalem Typ. 


PROCESS 
CONS 


start: integer := 


CONS finish: 
TYPE in 
VARIABL 

EGIN 
positional association, 


BE vO, vl, v2, v3, v4: 


t_vector IS ARRAY (start TO finish) 


integer : 
OF integer; 
int_vector; 


vo = (5,2,3,1,4,4,2,1) 


vo (50.223, 1 A421 
It! illegal: Mix aus positional 
vl (6, 2, 4 => 1, 5 => 3, O 
named association, 

v2 (2 TO 4 => start, 1| 5° 
named association mit OTHERS, 
v3 := (start | finish => 3*8, 
slice und aggregate, 
v4 (1 TO 3) (0, 0, 
v4 (4 TO 8) (8, 2, 


und named association 
ERS => 0); 

v2 = (8,1,1,1,8,8,8,8) 
TO 8 => finish); 
v3 (24,0,0,0,0,0,0,24) 
ERS => 0); 
(0,0,0,8,2,2,2,2) 


H 


OTHI 


0); 
2, 


END PROC 


ESS; 


3.4.3 Objekte mit zusammengesetztem Typ 


Bei zusammengesetzten Typen ("records") spricht man die Einzelele- 
mente mit sog. "selected names" an: 


record_name.record_element_name 


Der Referenzname des zusammengesetzten Typs (record_name) 
wird in der Objektdeklaration festgelegt, während der Name des anzu- 
sprechenden Einzelelements (record_element_name) aus der 
Typdeklaration stammt. 
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Die Zuweisung von kompletten Records oder von Einzelelementen 
kann auch über ein Aggregat ("positional" oder "named") erfolgen. 


ROCESS 

VARIABLE v_l, v_2, v_3 : complex; -- Deklaration s.o. 
EGIN 
v_l.real_part := 1.0; -- selected name 


v_l.imag_part := vl.real_part; selected nam 

v_2 =. (2,0551) -- posit. Aggregate 

v_3 := (real_part => 3.2, -- named Aggregate 
imag_part => 3.0); 


END PROCI 


3.5 Attribute 


Mit Hilfe von Attributen können bestimmte Eigenschaften von Objek- 
ten oder Typen abgefragt werden. Die Verwendung von Attributen 
kann eine VHDL-Beschreibung wesentlich kürzer und eleganter ge- 
stalten. Außerdem läßt sich mit Hilfe von Attributen der Anwendungs- 
bereich von VHDL-Modellen erhöhen. 


Attribute werden unter Angabe des Objekt- oder Typnamens als Prefix 
folgendermaßen verwendet: 


obj_or_type_name'attr_l_name{"'"attr_n_name} 


Attribute können also auch mehrfach angewandt werden. Dabei ist je- 
doch zu beachten, daß der Ergebnistyp des ersten Attributs und der 
Prefixtyp des zweiten Attributs übereinstimmen müssen. 


Es gibt sowohl eine Reihe von vordefinierten Attributen (Abschnitt 
6.2), als auch die Möglichkeit, benutzerdefinierte Attribute zu dekla- 
rieren und mit Werten zu versehen (Abschnitt 11.1). 
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Ein komplettes VHDL-Modell besteht aus mehreren Teilen (Design- 
Einheiten): einer Schnittstellenbeschreibung, der sog. "Entity", einer 
oder mehreren Verhaltens- oder Strukturbeschreibungen, den sog. 
"Architectures" und gegebenenfalls mehreren Konfigurationen, den 
sog. "Configurations". 


Die Aufteilung der einzelnen Design-Einheiten auf eine oder mehrere 
Dateien ist willkürlich; es muß lediglich die Reihenfolge beim Compi- 
lieren der einzelnen Design-Einheiten für die Simulation beachtet wer- 
den: Entity-Architecture-Configuration: 


m Stehen alle zu einem Modell gehörenden Design-Einheiten in 
einer Datei, dann müssen sie in der angegebenen Reihenfolge 
verfaßt sein, da der Compiler die Datei sequentiell abarbeitet. 


a Stehen die Design-Einheiten in verschiedenen Dateien, so müs- 
sen die Dateien in der entsprechenden Reihenfolge compiliert 
werden. 


Werden bestimmte Objekttypen, Funktionen oder Prozeduren von 
mehreren Modellen benötigt, so werden sie üblicherweise in unab- 
hängigen Einheiten, den sog. "Packages", abgelegt. 


4.1 Bibliotheken 


Struktural aufgebaute Modelle greifen auf hierarchisch tiefer liegende 
VHDL-Beschreibungen zu. Diese Abhängigkeiten von anderen Mo- 
dellen und Packages wird durch das Konzept der Bibliotheken 
("Libraries") gehandhabt. 


Bibliotheken dienen als Aufbewahrungsort für compilierte und (wie- 
der) zu verwendende Design-Einheiten. In einem Dateisystem werden 
die Bibliotheken meist als eigene Verzeichnisse realisiert. Damit dieses 
Konzept jedoch unabhängig von den Namenskonventionen eines be- 


94 © G. Lehmann/B. Wunder/M. Selz 


4 Aufbau eines VHDL-Modells 


stimmten Betriebssystems bleibt, werden die Bibliotheken nur über 
logische Namen (VHDL-Bezeichner) angesprochen. Der Bezug zwi- 
schen einem Verzeichnispfad und dem logischen VHDL-Namen wird 
in werkzeugspezifischen Konfigurationsdateien festgelegt oder über 
spezielle Aktionen hergestellt. 


Standardmäßig legt der VHDL-Compiler die compilierten Design-Ein- 
heiten in der Bibliothek mit dem logischen Namen work ab. Neben 
den Modellen aus dieser Bibliothek (auch als Working-Library be- 
zeichnet), können Modelle auch aus weiteren, sog. Resource-Libraries 
verwendet werden. 


Abb. B-2 zeigt diese Zusammenhänge: 


Simulations- 
VHDL- ergebnisse 
Code 
Compiler Simulator 


Working- 
Library 


Resource- 
Libraries 


Abb. B-2: Konzept der VHDL-Bibliotheken 


Innerhalb einer Bibliothek müssen die Namen (Bezeichner) der De- 
sign-Einheiten Package, Entity und Configuration eindeutig, d.h. 
unterscheidbar sein. Bei den Architekturen hingegen müssen nur die 
Bezeichner der zu ein- und derselben Entity gehörenden Architek- 
turen voneinander verschieden sein. 
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4.1.1 Die LIBRARY-Anweisung 


Vor dem Ansprechen eines Bibliotheksobjektes muß die verwendete 
Bibliothek der entsprechenden Design-Einheit bekanntgemacht wer- 
den. Dies geschieht durch folgende Anweisung: 


LIBRARY library_name_l {, library_name_n} ; 


Implizit (d.h. ohne LIBRARY-Anweisung) sind die Bibliotheken std 
und work bekannt. In std sind die allgemeinen Packages abgelegt. 
Die Bibliothek work dient, wie bereits erwähnt, zum Abspeichern ei- 
gener, compilierter Modelle. 


Die LIBRARY-Anweisung kann vor einer Entity, vor einer Architek- 
tur, vor einer Configuration, vor einem Package oder Package Body 
stehen (in der sog. "context clause" der Design-Einheiten). 


4.1.2 Die USE-Anweisung 


Nach der Bekanntgabe der Bibliothek geschieht das Ansprechen von 
Bibliothekselementen mit Hilfe von "selected names" durch den voran- 
gestellten logischen Bibliotheksnamen. Soll ein Element, das in einem 
Package definiert wurde, angesprochen werden, so muß zusätzlich zum 
Bibliotheksnamen der Package-Name im "selected name" enthalten 
sein: 


LIBRARY cmos_lib; 


a := cmos_lib.tech_data.cl; 
-- Konstante cl im Package tech_data der Library cmos_lib 


Das direkte Ansprechen von Funktionen und Modellen (d.h. ohne 
vorangestellten Bibliotheksnamen und Package-Namen) kann erfol- 
gen, wenn vor Verwendung des Elementes in einem VHDL-Modell 
eine USE-Anweisung eingesetzt wird, z.B.: 


USE library_name.ALL ; 
USE library_name.element_name ; 
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USE library_name.package_name.ALL ; 
USE library_name.package_name.element_name ; 


Damit sind alle bzw. nur die spezifizierten Elemente der Bibliothek 
oder des Packages sichtbar. In einer USE-Anweisung können, durch 
Kommata getrennt, auch mehrere Bibliothekselemente stehen. 


Die USE-Anweisung kann vor der Design-Einheit stehen, für die sie 
Gültigkeit haben soll, oder im Deklarationsteil von Design-Einheiten, 
Blöcken, Prozessen, Funktionen und Prozeduren sowie innerhalb der 
Packages. Der Gültigkeitsraum ist dementsprechend eingeschränkt. 


Implizit, d.h. auch ohne USE-Anweisung, sind alle Elemente des 
Packages std.standard sichtbar. Die Elemente des normierten 
Packages std.textio müssen explizit mit einer USE-Anweisung 
sichtbar gemacht werden. 


LIBRARY work, std; implizit enthalten 
USE std.standard.ALL; implizit enthalten 


USE std.textio.ALL; Elemente in textio sichtbar 
LIBRARY cmos_lib; Bib. cmos_lib qgueltig 
USE cmos_lib.tech_data.ALL; cl jetzt direkt ansprechbar 


4.2 _Schnittstellenbeschreibung (Entity) 


Die einzelnen Modelle eines komplexen VHDL-Entwurfs kommuni- 
zieren über die Entity, d.h. über deren Schnittstellenbeschreibung, mit- 
einander. Die "Kommunikationskanäle" nach außen sind die sog. Ports 
eines Modells. Für diese werden in der Entity Name, Datentyp und 
Signalflußrichtung festgelegt. 


Außerdem werden in der Schnittstellenbeschreibung die Parameter de- 
klariert, die dem Modell übergeben werden können (sog. "Generics"). 
Mit Hilfe dieser Parameter lassen sich beispielsweise die Verzöge- 
rungs- oder Set-Up-Zeiten eines Modells von außen an das Modell 
übergeben. Generics können auch die Bitbreite der Ports bestimmen 
oder den Namen einer Datei enthalten, in der die Programmierdaten 
eines PLA-Modells abgelegt sind. Auf diese Weise bieten Generics 
eine hohe Flexibilität bei der Konfiguration von Modellen, da eine 
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Änderung dieser Übergabeparameter kein Neu-Compilieren des Mo- 
dells erfordert. 


Neben den Ports und Generics können in der Schnittstellenbeschrei- 
bung Deklarationen gemacht werden, die für die Entity und damit 
auch für alle zugehörigen Architekturen Gültigkeit besitzen. 


Im optionalen Anweisungsteil ("Entity Statement Part", zwischen 
BEGIN und END) können darüberhinaus passive Prozesse, der Aufruf 
passiver Prozeduren oder nebenläufige Assertions stehen. Passiv be- 
deutet, daß keine Signalzuweisung innerhalb des Prozesses / der Pro- 
zedur erfolgt. 


Die Entity ist folgendermaßen aufgebaut: 


ENTITY entity_name IS 
[ GENERIC ( 
param_l {, param_n } : type_name 
[ := def_value ] 
{ ; further_generic_declarations be] 


[ PORT ( 
{ port_1 {, port_n } : IN type_name 
[ := def_value ] } 
{ ; port_declarations_of_mode_OUT } 
{ ; port_declarations_of_mode_INOUT } 
{ ; port_declarations_of_mode_BUFFER } );] 


USE-Anweisungen, Disconnections 
-- Deklaration von: 
-- Typen und Untertypen, Aliases, 
-- Konstanten, Signalen, Files, 
-- Unterprogrammen, Attributen 
-- Definition von: 
-- Unterprogrammen, Attributen 
-- VHDL'93: Groups, Shared Variables 


-- passive Befehle, Assertions 


a >] 
END [ENTITY] [entity_name] ; 
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Die optionale Wiederholung des Schlüsselwortes ENTITY in der END- 
Anweisung ist nur in Vg3 möglich. 


Mit jeder Port-Deklaration der Entity wird implizit ein Signal gleichen 
Typs und gleichen Namens deklariert, das unter bestimmten Ein- 
schränkungen - abhängig vom Modus des Ports - in der Entity und in 
den zugehörigen Architekturen verwendet werden kann: 


71 Modus IN: Ports können nicht geschrieben werden, 

71 Modus OUT: Ports können nicht gelesen werden, 

{J Modus INOUT: Ports können gelesen und geschrieben werden, 
71 Modus BUFFER: Ports können gelesen und nur von einer Quel- 


le geschrieben werden. 


Zusätzliche interne Signale müssen im Deklarationsteil der Entity oder 
der Architektur deklariert werden. 


Ein einfaches Beispiel für eine Entity (NAND3-Gatter): 


ENTITY nand3 IS 

GENERIC ( delay : TIME := 2.2 ns 

PORT (a,b, c : IN std_ulogic : 
y : OUT std_ulogic 


TYPE tristate IS ('0', '1', '2'); 
EGIN 
ASSERT ((a /= 'X') AND (b /= 'X') AND (c /= 
EPORT "Ungueltiger Wert am Eingang"; 
END nand3; 


4.3 Architektur (Architecture) 


Die Architektur enthält die Beschreibung der Modelleigenschaften. 
Diese Beschreibung kann sowohl aus der Verhaltenssichtweise als auch 
aus der strukturalen Sichtweise erfolgen. Ein bestimmtes Modell kann 
also durch sein Verhalten oder durch seinen Aufbau (interne Module 
und deren Verbindungen) beschrieben werden. Mischformen beider 
Beschreibungsvarianten sind innerhalb eines Modells möglich. 


Einer Schnittstellenbeschreibung können keine, eine oder mehrere Ar- 
chitekturen besitzen; beispielsweise kann eine Architektur eine Model- 
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lierung auf Register-Transfer-Ebene enthalten, während die andere ei- 
ne technologiespezifische Beschreibung auf Logikebene mit detaillier- 
ten Verzögerungszeiten bereitstellt. 


Auch die Architektur besteht aus einem Deklarationsteil (vor BEGIN) 
für lokale Typen, Objekte, Komponenten usw. und einem Bereich mit 
Anweisungen, dem "Architecture Statement Part" (zwischen BEGIN 
und END). Dieser enthält die eigentliche Modellbeschreibung. 


Der prinzipielle Aufbau einer Architektur ist wie folgt: 


ARCHITECTURE arch_name OF entity_name IS 


-- USE-Anweisungen, Disconnections 
-- Deklaration von: 

-- Typen und Untertypen, 

-- Aliases, Konstanten, 

-- Signalen, Files, Komponenten, 
-- Unterprogrammen, Attributen 

-- Definition von: 

-- Unterprogrammen, Attributen, 

-- Konfigurationen 


-- VHDL'93: Groups, Shared Variables 


-- nebenlaeufige Anweisungen 
-- zur strukturalen Modellierung 
-- und Verhaltensmodellierung 


END [ARCHITECTURE] [arch_name]; 


Die Wiederholung des Schlüsselwortes ARCHITECTURE in der END- 
Anweisung ist mit Vg3 optional möglich. 


Im Unterschied zu Programmiersprachen, wie z.B. "C", hat VHDL die 
Aufgabe, neben rein sequentiellen Funktionsabläufen auch Hardware 
zu beschreiben. Die in einer Hardwareeinheit enthaltenen Funktions- 
module arbeiten aber nicht ausschließlich sequentiell, sondern parallel, 
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d.h. die einzelnen Funktionen laufen nicht immer nacheinander, son- 
dern eventuell auch gleichzeitig ab. 


Um diese Eigenschaft zu beschreiben, wird das Konzept der parallelen 
(nebenläufigen, oder auch "concurrent") Anweisungen verwendet, die 
im Idealfall gleichzeitig bearbeitet werden. Da die Simulation eines 
VHDL-Modells in der Regel jedoch auf einem Prozessor abläuft, ist 
dies nicht möglich. Deshalb wurde ein spezieller Simulationsalgorith- 
mus entwickelt, der ein "quasi paralleles", d.h. für den Benutzer nicht 
direkt sichtbares, sequentielles Abarbeiten der nebenläufigen Befehle 
gestattet. Dieser Ablauf wird in Kapitel 8 erläutert. 


Aus oben genanntem Grund sind die VHDL-Anweisungen in zwei 
Kategorien einzuteilen: sequentielle und nebenläufige Anweisungen. 


Innerhalb des Anweisungsteils einer Architektur sind alle Sprachkon- 
strukte nebenläufig. Nebenläufige Anweisungen sind z.B. die Instan- 
tiierung von Komponenten, die BLOCK- und GENERATE-Anweisun- 
gen sowie insbesondere auch sämtliche Prozesse: 


<= ... (Signalzuweisung) GENERATE-Anweisung 
ASSERT-Anweisung PROCESS-Anweisung 
BLOCK-Anweisung Prozeduraufruf 


Komponenteninstantiierung 


Sequentielle Anweisungen entsprechen den von Programmiersprachen 
her bekannten Konstrukten. Sie dürfen nur innerhalb von Prozessen, 
Funktionen oder Prozeduren stehen: 


<= .„.. (Signalzuweisung) NEXT-Anweisung 


:= .„.. (Variablenzuweis.) NULL-Anweisung 


ASSERT-Anweisung Prozeduraufruf 
CASE-Anweisung REPORT-Anweisung 93 
EXIT-Anweisung RETURN-Anweisung 
IF-Anweisung WAIT-Anweisung 


LOOP-Anweisung 
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4.4 Konfiguration (Configuration) 


Die Design-Einheit Konfiguration dient zur Beschreibung der Kon- 
figurationsdaten eines VHDL-Modells. Zunächst wird darin festgelegt, 
welche Architektur zu verwenden ist. Bei strukturalen Beschreibungen 
kann außerdem angegeben werden, aus welchen Bibliotheken die ein- 
zelnen Submodule entnommen werden, wie sie eingesetzt (verdrahtet) 
werden und welche Parameterwerte (Generics) für die Submodule gel- 
ten. Eine Entity kann mehrere Konfigurationen besitzen. 


In der Konfiguration wird zwischen deklarativen und den eigentlichen 
Konfigurationsanweisungen unterschieden. Die Konfigurationsanwei- 
sungen beschreiben - gegebenenfalls hierarchisch - die Parameter und 
Instanzen der verwendeten Architektur. 


Die Rahmensyntax der Design-Einheit Konfiguration lautet wie folgt: 


CONFIGURATION conf_name OF entity_name IS 


-- USE- Anweisungen und 
-- Attributzuweisungen, 
-- Konfigurationsanweisungen 


END [CONFIGURATION] [conf_name] ; 


Die optionale Wiederholung des Schlüsselwortes CONFIGURATION 
ist wieder nur in Vg3 gestattet. 


Da die Sprache VHDL in hohem Maße die Wiederverwendung existie- 
render Modelle unterstützen soll, bietet sie eine Vielzahl an Konfigura- 
tionsmöglichkeiten. Aus diesem Grund wird in Kapitel 7 des Teils B 
näher auf die Details dieser Design-Einheit eingegangen. 


4.5 Package 


Packages dienen dazu, häufig benötigte Datentypen, Komponenten, 
Objekte, etc. einmalig zu deklarieren. Diese Deklarationen können 
dann in verschiedenen VHDL-Modellen verwendet werden. Packages 
eignen sich insbesondere, um globale Informationen innerhalb eines 
komplexen Entwurfs oder innerhalb eines Projektteams einmalig und 
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damit widerspruchsfrei festzulegen. Typische Anwendungen sind 
Packages, die einen bestimmten Logiktyp (z.B. vierwertige Logik) und 
die zugehörigen Operatoren beschreiben. Andere Packages könnten 
beispielsweise eine Sammlung von mathematischen Funktionen 
(sin(x),cos (x), etc.) enthalten. 


VHDL unterscheidet zwischen Package und Package Body, die beide 
eigenständig sind und auch getrennt compiliert werden. Ursache für 
diese Vereinbarung sind die Abhängigkeiten beim Compilieren der 
Design-Einheiten. Da die anderen Design-Einheiten auf den verwen- 
deten Packages aufbauen, müßten bei der Änderung eines Unterpro- 
gramms im Package alle vom Package abhängigen Design-Einheiten 
neu compiliert werden. Durch die Trennung von Deklaration (ent- 
halten im Package) und Funktionalität bzw. Definition (enthalten im 
Package Body) kann dies vermieden werden. Entities, Architectures 
und Configurations basieren nur auf den Deklarationen des Packages. 
Änderungen im Package Body erfordern damit kein Neu-Compilieren 
der übrigen Design-Einheiten. Dieses Konzept, das auch als "defer- 
ring" bezeichnet wird, unterstützt die Änderungsfreundlichkeit der 
VHDL-Modelle ("deferring" steht für "Verschiebung" der Implemen- 
tierung in den Package Body). 


Die Syntax der Design-Einheit Package lautet wie folgt: 
PACKAGE pack_name IS 

-- USE-Anweisungen, Disconnections 
-- Deklarationen von: 
-- Typen und Untertypen, 
-- Aliases, Konstanten, 
-- Signalen, Files, Komponenten, 
-- Unterprogrammen, Attributen 


-- Definition von: 
-- Attributen 


-- VHDL'93: Groups, Shared Variables 


END [PACKAGE] [pack_name] ; 


Das Schlüsselwort PACKAGE kann nur in V93 wiederholt werden. 
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Der Package Body kann neben der Definition von Unterprogrammen 
auch spezielle Deklarationsanweisungen enthalten. Der Zusammen- 
hang mit dem Package wird durch den identischen Namen (pack_ 
name) hergestellt. Der Package Body weist folgende Struktur auf: 


PACKAGE BODY pack_name IS 


-- Deklarationen von: Typen und 
Untertypen, Aliases, Konstanten, 

-- Files, Unterprogrammen 

-- Definition von: Unterprogrammen 
USE-Anweisungen 


END [PACKAGE BODY] [pack_name] ; 


Die optionale Wiederholung der Schlüsselworte PACKAGE BODY ist 
wiederum nur in Vg3 möglich. 


PACKAGE fft_projekt IS 

TYPE tristate IS ('0', '1', '2'); 

CONSTANT standard_delay : time; ohne Wertangabe! 
END fft_projekt; 


PACKAGE BODY fft_projekt IS 
CONSTANT standard_delay : time := 2 ns; 


-- Wiederholung der Deklaration, 
-- Wertangabe aber nur im Package Body: "deferring" 
END fft_projekt; 


4.6 Abhängigkeiten beim Compilieren 


Die bei der Erläuterung der Packages bereits angeklungenen Abhän- 
gigkeiten beim Compilieren der Design-Einheiten werden in Abb. B-3 
illustriert. Beispielsweise müssen nach einer Änderung in einer Entity 
auch alle zugehörigen Architekturen und Konfigurationen neu 
übersetzt werden. Eine Änderung im Package Body erfordert dagegen 
nur das erneute Compilieren dieser Design-Einheit. 
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Abb. B-3: Abhängigkeiten beim Compilieren von VHDL-Modellen 


Package Body 
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Strukturale Modellierung bedeutet im allgemeinen die Verwendung (= 
Instantiierung) und das Verdrahten von Komponenten in Form einer 
Netzliste. VHDL bedient sich dazu einer dreistufigen Vorgehensweise, 
die zwar viele Freiheitsgrade bietet, für den Anfänger jedoch sehr un- 
übersichtlich ist. Zur Einführung in die strukturale Modellierung soll 
deshalb ein RS-Flip-Flop betrachtet werden, das aus zwei gleichartigen 
NAND2-Gattern aufgebaut ist (siehe Abb. B-4). 


Abb. B-4: Struktur eine RS-Flip-Flops 


Die Schnittstelle des RS-Flip-Flops hat folgendes Aussehen: 


ENTITY rs_ff IS 
PORT (r_bar, s_bar : IN bit := '0'; 


g, q_bar : INOUT bit); 


-- Ports als INOUT, da sie auch gelesen werden muessen 
END rs_ff; 


Für die strukturale Modellierung des Flip-Flops mit der Sprache 
VHDL wird eine Komponentendeklaration, zwei Komponentenin- 
stantilerungen und eine Komponentenkonfiguration benötigt: 
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ARCHITECTURE structural OF rs_ff IS 
COMPONENT nand2_socket -- Komponentendeklaration 
PORT (a, b : IN bit; y : OUT bit); 
END COMPONENT; 
EGIN 
nand_a : nand2_socket -- Komponenteninstantiierung 
PORT MAP (a => r_bar, b => q, y => q_bar); 
nand_b : nand2_socket -- Komponenteninstantiierung 
PORT MAP (a => q_bar, b => s_bar, y => q); 
END structural; 


CONFIGURATION rs_ff_config OF rs_ff IS 
FOR structural 
FOR ALL : nand2_socket -- Komponentenkonfiguration 
USE ENTITY work.nand2 (behavioral); 
END FOR; 
END FOR; 
END rs_ff_config; 


Für ein besseres Verständnis kann man sich diese dreistufige VHDL- 
Syntax mit ICs und zugehörigen Sockeln bzw. Sockeltypen vorstellen. 
Das strukturale Modell des Flip-Flops würde also eine Leiterplatte mit 
zwei gesockelten NAND2-Gattern nachbilden. 


m) Komponentendeklaration 
Als erster Schritt wird ein Prototyp des Komponentensockels im 
Deklarationsteil der Architektur, im Deklarationsteil eines Blocks 
oder im Package deklariert (hier: nand2_socket). 


m Komponenteninstantiierung 
In der Architektur / im Block werden Instanzen dieses Sockel- 
typs gebildet und verdrahtet (hier: nand_a undnand_b). 


m Komponentenkonfiguration 

In der Konfiguration schließlich wird festgelegt, welches bereits 
compilierte VHDL-Modell für die jeweiligen Instanzen der 
Komponenten einer strukturalen Architektur verwendet wird; 
mit anderen Worten: welcher IC-Typ in die einzelnen Sockel 
eingesetzt wird. Im Beispiel wird für alle Instanzen der Kompo- 
nente nand2_socket die Entity nand2 aus der Bibliothek 
work verwendet (in Klammern: zugehörige Architektur). 
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5.1 Komponentendeklaration und 
-instantiierung 


In einer Komponentendeklaration werden im allgemeinen neben den 
Ports (entsprechend den Pins des Sockeltyps) auch die zu übergeben- 
den Parameter (Generics) aufgeführt. Die Komponentendeklaration ist 
somit ein Abbild der Entity des einzusetzenden Modells (ICs). 


COMPONENT comp_name 
[ GENERIC ( 


param_1l {, param_n } : type_name 
[ := def_value ] 
{ ; further_generic_declarations } )>] 
[ PORT ( 
{ port_1 {, port_n } : IN type_name 


[ := def_value ] } 
{ ; port_declarations_of_mode_OUT } 
{ ; port_declarations_of_mode_INOUT } 
{ ; port_declarations_of_mode_BUFFER } );] 
END COMPONENT ; 


Auch hier greift die Vereinheitlichung der Rahmensyntax von V 93, so 
daß sich folgende Syntax-Alternative ergibt: 


COMPONENT comp_name [IS] 


END COMPONENT [comp_name] ; 


Einige Beispiele von Komponentendeklarationen: 


COMPONENT inv 

GENERIC (tpd_lh, tpd_hl : time := 0.8 ns) ; 
PORT (a : IN bit; y : OUT bit) ; 

END COMPONENT ; 


COMPONENT or2 

GENERIC (tpd_lh : time := 1.5 ns; tpd_hl : time := 1 ns) ; 
PORT (a,b : IN bit; y : OUT bit) ; 

END COMPONENT ; 
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COMPONENT and2 

GENERIC (tpd_lh : time := Ins; tpd_hl : 
PORT (a,b : IN bit; y : OUT bit) ; 

END COMPONENT ; 


COMPONENT and3 

GENERIC (tpd_lh : time := Ins; tpd_hl : 
PORT (a,b,c : IN bit; y : OUT bit) ; 

END COMPONENT ; 


Die eigentliche Netzliste wird erst durch das Instantiieren dieser Sok- 
keltypen und gleichzeitiges Verdrahten durch Zuweisung von Signal- 
namen an die Ports erzeugt. Dabei können auch Parameter übergeben 
werden. 


Jede Komponente erhält bei der Instantiierung einen eigenen Refe- 
renznamen (inst_name): 


inst_name : comp_name 
[ GENERIC MAP ( ...) ] Generic-Map-Liste 
[ PORTMAP (...) ]; -- Port-Map-Liste 


Es existieren verschiedene Möglichkeiten, die Ports und Parameter von 
Komponente und zugehöriger Instanz zuzuordnen. Um die dafür er- 
forderliche Syntax zu verstehen, sind zunächst folgende Ebenen zu 
unterscheiden: 


I Ports und Generics in der Schnittstellenbeschreibung (Entity) 
der zu instantiierenden Komponente (sog. "formals"), 


I Ports und Generics in der Komponentendeklaration (sog. 
"Jocals") und 


I lokale Signale innerhalb der Architektur oder die von der Archi- 
tektur zu übergebenden Parameterwerte (sog. "actuals"). 


Bei der Komponenteninstantiierung innerhalb von strukturalen Archi- 
tekturen werden locals mit actuals verbunden. Angaben von Parame- 
terwerten in der Generic-Map überschreiben dabei die Defaultwerte in 
der Komponentendeklaration. 
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Generic-Map und Port-Map bestehen: 


m aus einer durch Kommata getrennten Liste von unmittelbar auf- 
einanderfolgenden Signalnamen (actuals) bzw. Parameterwer- 
ten, wobei die Zuweisung in der gleichen Reihenfolge wie in der 
Komponentendeklaration (locals) erfolgt ("positional asso- 
ciation"): 

actual_l {, actual_ln} 


m oder aus einer durch Kommata getrennten Liste von expliziten 
Zuweisungen in beliebiger Reihenfolge ("named association"): 


local_1 => actual_l 
{, local_n => actual_n} 


a oder aus einer Kombination beider Möglichkeiten, wobei die 
zweite Variante der ersten nachfolgen muß. 


Das folgende Beispiel für eine strukturale Architektur greift die oben 
gezeigten Komponentendeklarationen auf. Es handelt sich um ein 3- 
2-AND-OR-INVERT-Komplexgatter mit folgendem Schaltbild: 


al structural_1 
27] a and_a a_out 
zZ b y 
a3 | 


> > c 


Abb. B-5: Schaltbild eines 3-2-AND-OR-INVERT-Komplexgatters 


ENTITY aci IS 
PORT ( al, a2, a3, kl, b2 : IN bit; 
y : OUT bit ) ; 


END aci ; 
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ARCHITECTURE structural_1 OF aoi IS 


SIGNAL a_out, b_out, or_out : bit ; -- interne Signale 


-- Komponentendeklarationen wie oben 


EGIN 
verschiedene Varianten der Instantiierung: ------------ 
-- position. association, tpd_lh = 1.2 ns, tpd_hl = 2.4 ns 
and_a : and3 GENERIC MAP (1.2 ns,2.4 ns) 
PORT MAP (al,a2,a3,a_out) ; 
-- named association 
and_b : and2 GENERIC MAP (tpd_hl=>1.9 ns,tpd_lh=>1.1 ns) 
PORT (b=>bl, y=>b_out,a=>b2) ; 
ohne Generic : Default Generics: 1.5 ns bzw. 1.0 ns 
SL.&. # 8r2: PORT (a_out, y=>or_out,b=>b_out) ; 
-- unvollst. Generic-Map: tpd_hl = Defaultwert: 0.8 ns 
inv_d : inv GENERIC MAP (0.7 ns) PORT MAP (or_out,y) ; 
END structural_1 


Zusätzlich zu diesem Beispiel sei noch auf die einfachere Architektur 
structural des Halbaddierers aus Teil A zur Verdeutlichung der 
strukturalen Modellierung verwiesen. 


Erlaubt ist in VHDL auch das Schlüsselwort OPEN als actual zur 
Kennzeichnung nicht angeschlossener Ports (nicht verdrahteter Sok- 
kelpins). Für solche Ports wird bei Simulationsbeginn der Defaultwert 
angenommen, der in der Komponentendeklaration angegeben ist. 


Eine weitere Vereinbarung für Eingangsports in der Syntax Y'93 er- 
laubt die Angabe von Ausdrücken als actuals. 


Ein Beispiel verdeutlicht die Möglichkeiten von nicht angeschlossenen 
Ports bzw. die Zuweisung von Ausdrücken nach /g3. Es handelt sich 
um das obige Komplexgatter mit veränderter Architektur. Der Inverter 
und das ODER-Gatter sind hier zu einem NOR-Gatter zusammen- 
gefaßt. 
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ARCHITECTURE structural_2 OF aci IS -- !!! VHDL'93 !!! 
SIGNAL a_out, b_out : bit ; -- interne Signale 
COMPONENT nor3 invertierendes OR3 
PORT (a,b,c : IN bit : - : OUT kit) ; 

END COMPONENT nor3; 

COMPONENT and3 -- nur 3-fach AND 

PORT (3,b,€% + IN DIE:; ; : OUT kit) ; 

END COMPONENT ; 

BEGIN 
and_a : and3 PORT MAP (al,a2,a3,a_out) ; 
and_b : and3 PORT MAP (a=>b2,b=>bl,c=>'1',y=>b_out) ; 

-- VHDL'93: Port "c" wird konstant auf '1' gelegt 
nor_c : nor3 PORT MAP (OPEN, a_out, y=>y,b=>b_out) ; 
-- VHDL'87/93: Port "a" bleibt unangeschlossen: '0' 

END structural_2 ; 


Mit Vg93 wurde eine Möglichkeit geschaffen, bereits bei der Kompo- 
nenteninstantiierung anzugeben, welches Modell zu verwenden ist. 
Diese sog. "direkte Instantiierung” kann mit dem Einlöten eines ICs in 
die Leiterplatte ohne Sockel verglichen werden. Bei einmalig verwen- 
deten Komponenten hat dies durchaus Vorteile, mehrfach verwendete 
Komponenten hingegen sollten mit der herkömmlichen Methode in- 
stantiiert werden. 


Die direkte Instantiierung Vg3 benötigt weder eine Komponentende- 
klaration noch eine Konfiguration. Sie hat folgende Syntax: 


inst_name : CONFIGURATION config_name 
[ GENERIC MAP ( ...) ] Generic-Map-Liste 
[ PORTMAP (...) ]; -- Port-Map Liste 
inst_name : ENTITY entity_name [(arch_name)] 
[ GENERIC MAP ( ...) ] Generic-Map-Liste 
[ PORTMAP (...) l; -- Port-Map-Liste 


Wird im zweiten Fall keine Architektur angegeben, so wird die Entity 
ohne Architektur instantiiert. Dies ist u.a. dann sinnvoll, wenn die 
Funktion des Modells nur im Anweisungsteil der Entity (durch passive 
Prozeduren, Prozesse und Assertions) definiert ist. 
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Natürlich ist die herkömmliche Instantiierung in YVg3 weiterhin er- 
laubt. Das Schlüsselwort COMPONENT kann nun hinzugefügt werden: 


inst_name : [ COMPONENT ] comp_name 
[ GENERIC MAP ( ...) ] Generic-Map-Liste 
[ PORT MAP (...) ]; -- Port-Map Liste 


Als Beispiel für die direkte Instantiierung in Y'g3 soll wieder das 
Komplexgatter dienen. Man beachte, daß für diese Version weder 
Komponentendeklarationen noch eine Konfiguration benötigt werden: 


ARCHITECTURE structural_3 OF aci IS -- !! VHDL'93-Syntax !! 
SIGNAL a_out, b_out : bit ; -- interne Signale 

BEGIN 
and_a : ENTITY work.and3 (behavioral) 

PORT MAP (al,a2,a3,a_out) ; 


and_b : ENTITY work.and2 (behavioral) 


PORT MAP (b1,b2,b_out) ; 
nor_c : CONFIGURATION work.nor2_config 
PORT MAP (a_out,b_out,y) ; 
END structural_3 ; 


5.2 BLOCK-Anweisung 


Die BLOCK-Anweisung dient zur Gliederung eines Modells, ohne eine 
Modellhierarchie mit instantiierten Untermodellen einführen zu müs- 
sen. Ähnlich einer Architektur können in einem Block lokale Deklara- 
tionen getroffen werden. Ein Block kann sogar wie eine eigenständige 
Einheit mit Generics und Ports verwaltet werden. Auch ist es möglich, 
daß innerhalb eines Blocks wieder eine Partitionierung in Blöcke statt- 
findet, so daß sich prinzipiell in einer Architektur beliebig komplexe 
Strukturen aufbauen lassen. 


Die Syntax von Blöcken hat folgende Form: 


block_name : BLOCK [IS] 


USE-Anweisungen, Disconnections 
-- Generics und Generic-Map 
-- Ports und Port-Map 
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-- Deklaration von: 

-- Typen und Untertypen, 

-- Aliases, Konstanten, 

-- Signalen, Files, Komponenten, 
-- Unterprogrammen, Attributen 
-- Definition von: 

-- Unterprogrammen, Attributen 
-- Konfigurationen 


-- VHDL'93: Groups, Shared Variables 


nebenlaeufige Anweisungen 
-- zur strukturalen Modellierung 
-- und Verhaltensmodellierung 


END BLOCK [block_name] ; 


Die Verwendung des Schlüsselwortes IS in der BLOCK-Anweisung ist 
nur in /g3 möglich. 


Als Beispiel für die Block-Anweisung dient erneut das AOI-Komplex- 
gatter, das nun in zwei Stufen partitioniert wurde. Die beiden Stufen 
sind als Blöcke realisiert (siehe Abb. B-6). Der zweite Block hat zur 
Veranschaulichung der BLOCK-Syntax eigene Ports mit einer ent- 
sprechenden Port-Map. 


structural_4 


nor_stage 


Abb. B-6: Strukturierung des Komplexgatters durch Blöcke 
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ARCHITECTURE structural_4 OF aoi IS 

SIGNAL a_out, b_out : bit ; -- interne Signale 
BEGIN 

and_stage : BLOCK 

COMPONENT and2 

PORT (a,b : IN bit; y : OUT bit) ; 
END COMPONENT ; 
COMPONENT and3 

PORT (a,b,c : IN bit; y : OUT kit) ; 
END COMPONENT ; 
EGIN 
and_a : and3 PORT MAP (al,a2,a3,a_out); 
and_b : and2 PORT MAP (b1,b2,b_out); 


END BLOCK and_stage; 


nor_stage : BLOCK 
PORT (aa,bb : IN bit; yy : OUT bit) ; 
PORT MAP (aa=>a_out, bb=>b_out, yy=>y); 
SIGNAL cc : bit; -- block-internes Signal 
COMPONENT or2 -- nicht invertierend ! 
PORT (a,b : IN bit; y : OUT bit) ; 

END COMPONENT ; 

EGIN 

or_c : or2 PORT MAP (a=>aa,b=>bb,y=>cc) ; 

yy <= not cc; -- Invertierung 

END BLOCK nor_stage ; 

D structural_4 ; 


5.3 GENERATE-Anweisung 


In vielen Fällen treten in elektronischen Systemen regelmäßige Struk- 
turen auf, bei denen ein Modul aus mehreren gleichartigen Submo- 
dulen besteht. Eine Darstellung solcher Strukturen mit den bisher ein- 
geführten Beschreibungsmitteln der Sprache VHDL würde sehr um- 
fangreich werden. Mit Hilfe der GENERATE-Anweisung lassen sich je- 
doch regelmäßige Strukturen einfach und auch flexibel gestalten. 


Abhängig von einer Bedingung (condition) oder einem diskreten 
Bereich (disc_range) wird eine Reihe von nebenläufigen Anwei- 
sungen ein- oder mehrfach ausgeführt. Der diskrete Bereich kann wie 
gewohnt durch zwei diskrete Bereichsgrenzen und eines der beiden 
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Schlüsselwörter TO oder DOWNTO bzw. mit einem diskreten Werte- 
bereich mit Hilfe des Attributs RANGE angegeben werden: 


gen_name : IF condition GENERATE 


Nebenlaeufige Anweisungen 


END GENERATE [gen_name] ; 


gen_name : FOR var_name IN disc_range GENERATE 


Nebenlaeufige Anweisungen 


END GENERATE [gen_name] ; 


Bei der zweiten Beschreibungsvariante wird eine Laufvariable für den 
Index durch die Rahmensyntax automatisch deklariert; sie kann inner- 
halb der Anweisung verwendet werden. Typische Anwendungsfälle für 
GENERATE-Anweisungen sind aus mehreren Speicherelementen auf- 
gebaute Register. Hierzu ein Beispiel (Abb. B-7): 


Ten ou Fr. ou rennen ou) ä 


Abb. B-7: n-Bit Register (n=4) 


ENTITY n_bit_register IS 
GENERIC (n : IN positive : 
PORT (clk : IN bit ; 


reg_in : IN bit_vector (n-1 DOWNT 
reg_out : OUT bit_vector (n-1 DOWNT 
END n_bit_register ; 
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ARCHITECTURE structural OF n_bit_register IS 
COMPONENT d_ff_socket 
PORT (d, clk : IN bit ; q : OUT bit) ; 
END COMPONENT ; 


EGIN 


reg : FOR i IN n-1 DOWNTO 0 GENERATE 
d_ff_instance : d_ff_socket 
PORT MAP (reg_in(i),clk, reg_ou 
END GENERATE ; 
D structural ; 


Die Länge dieses Registers ist in der Beschreibung nicht fixiert. Sie 
kann erst beim Konfigurieren des Modells über den Parameter n fest- 
gelegt werden. Damit lassen sich von diesem Modell auch mehrere In- 
stanzen unterschiedlicher Länge erzeugen. 


Falls nicht alle Instanzen nach dem gleichen Schema verdrahtet sind, 
müssen in der GENERATE-Anweisung Bedingungen eingesetzt wer- 
den. Als Beispiel dient hier ein Schieberegister beliebiger Länge, bei 
dem das erste und letzte Modul eine spezielle Verdrahtung besitzen 
(Abb. B-8): 


intern(1) intern(2) intern(3) 
ser_in ser_out 


Abb. B-8: n-Bit Schieberegister (n=4) 


ENTITY shift_register IS 
GENERIC (n: IN positive RANGE 2 TO 64 : 


PORT (clk, ser_in : IN bit ; 
ser_out &» OUT DIE) 45 
END shift_register ; 
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ARCHITECTURE structural OF shift_register IS 
SIGNAL intern : bit_vector (1 TO n-l) ; 
COMPONENT d_ff_socket 
PORT (d, celk : IN bit ; q : OUT bit) ; 

END COMPONENT ; 

BEGIN 
reg : FOR i IN n DOWNTO 1 GENERATE 

-- erstes D-FF: mit Eingang verdraht 

reg_begin : IF i = 1 GENERATE 
d_ff_begin : dA_ff_socket 
PORT MAP (ser_in,clk,intern(i)) ; 
END GENERATE ; 
mittlere D-FFs 
reg_middle : IF i > 1 AND i < n GENERATE 
ad_ff_middle : d_ff_socket 
PORT MAP (intern (i-1),clk,intern (i)) ; 
END GENERATE ; 
-- letztes D-FF: mit Ausgang verdrahtet 
reg_end : IF i = n GENERATE 
d_ff_end : d_ff_socket 
PORT MAP (intern (i-1),clk,ser_out) ; 

END GE . 

END GENE 

D struc 


Mit /93 wird ein optionaler Deklarationsteil für die GENERATE-An- 
weisung ermöglicht. Er entspricht dem Deklarationsteil von BLOCK 
oder ARCHITECTURE: 


gen_name : FOR var_name IN disc_range GENERATE 
[ 


Deklarationsteil 


BEGIN ] 


END GENERATE [gen_name] ; 


Die gleiche Erweiterungsmöglichkeit von / 93 gilt auch für die IF- 
Variante der GENERATE-Anweisung. 
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Im vorangegangenen Kapitel wurde gezeigt, wie sich hierarchische 
Strukturen, wie z.B. die in Abb. B-9 gezeigte, modellieren lassen. Die 
unterste Ebene in den einzelnen Zweigen des Strukturbaumes jedoch 
kann nicht struktural beschrieben werden, da diese Modelle nicht 
weiter in Sub-Modelle unterteilt sind. Für diese Modelle stellt VHDL 
zahlreiche Konstrukte zur Verfügung, mit denen sich das Modell- 
verhalten nachbilden läßt. 


S Strukturmodell 
V Verhaltensmodell 
S/V komb. Modell 


Abb. B-9: Hierarchischer Modellaufbau 


Als einführendes Beispiel zur Verhaltensmodellierung soll das nach- 
stehende Modell eines Zählers dienen, der bei steigenden Taktflanken 
zyklisch von O bis 4 zählt, falls der enable-Eingang den Wert '1' 
besitzt. Mit einem low-aktiven reset-Signal kann der Zähler asyn- 
chron zurückgesetzt werden. 


ENTITY count5 IS 
PORT (clk, enable, reset : IN kit; 


q : OUT bit_vector (2 DOWNTO 0)); 
END count5; 
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ARCHITECTURE behavioral OF count5 IS 
SIGNAL state : integer RANGE 0 TO 4 := 0; -- Zaehlerstand 
BEGIN 
count : PROCESS (clk, reset) Prozess zum Zaehlen 
BEGIN 
IF reset = '0' THEN 
state <= 0; Ruecksetzen 
ELSIF (enable = '1' AND c1k'EVE AND clk = '1') THE 
IF state < 4 THEN 
state <= state + 1; Hochzaehlen 
ELSE 
state <= 0; Ueberlauf 
END IF; 
END IF; 
END PROCESS count; 
nebenlaeufige Signalzuweisung an den Ausgang q 
qg <= ('0','0','0') WHEN state = 0 ELSE 
('0','0','1') WHEN state = 1 ELSE 
('0','1','0') WHEN state = 2 EL 
('0','1','1') WHEN state = 3 EL 
(1,0%, 80); 
END behavioral; 


Wie aus dem Beispiel hervorgeht, beschreibt die Verhaltensmodel- 
lierung, wie die Eingangs- in Ausgangssignale überführt werden. Ein- 
gesetzt werden bei einer Verhaltensmodellierung u.a. verschiedene 
Operatoren (AND, <, =), vordefinierte Attribute (EVENT), Signalzu- 
weisungen (q <= ...) oder IF-ELSIF-ELSE-Anweisungen. 
Selbstverständlich können innerhalb eines VHDL-Modells auch Kon- 
strukte der strukturalen und der Verhaltensmodellierung gleichzeitig 
verwendet werden. 


In den folgenden Abschnitten werden die VHDL-Sprachelemente vor- 
gestellt, die vorrangig der Verhaltensmodellierung dienen. 


Die nächsten beiden Abschnitte erläutern zunächst die Details der 
Anwendung von Operatoren und Attributen. Der "eilige" Leser Kann 
diese beiden Abschnitte, die eher zum Nachschlagen dienen, über- 
springen. 
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6.1 Operatoren 


Operatoren verknüpfen zwei Operanden bzw. verändern einen Ope- 
randen. Das Ergebnis kann wieder als Operand verwendet werden. 
Werden in einer Anweisung mehrere Operatoren ohne Klammerung 
eingesetzt, so ist die Priorität der Operatoren bei der Abarbeitung rele- 
vant. Bei gleicher Priorität werden die Operatoren in der Reihenfolge 
ihres Auftretens abgearbeitet. Die Anwendung der Operatoren wird in 
späteren Beispielen verdeutlicht. 


Abb. B-10 gibt die Priorität der einzelnen Operatoren untereinander 
an: 


Diverse Operatoren höchste Priorität 


Multiplizierende Operatoren Ann 


Signum-Operatoren 
Addierende Operatoren 
Vergleichsoperatoren 


Logische Operatoren niedrigste Priorität 


Abb. B-10: Prioritäten von Operatoren 


© G. Lehmann/B. Wunder/M. Selz 121 


B Die Sprache VHDL 


6.1.1 Logische Operatoren 


Logische Operatoren wirken auf Einzelobjekte oder Vektoren vom 
Typ bit oder boolean; das Ergebnis von logischen Operatoren ist 
entweder gleich '1' bzw. true oder gleich '0' bzw. false. 
VHDL kennt folgende logische Operatoren: 


I NOT Negation (nur ein rechtsstehender Operand) 
79 AND UND-Verknüpfung 

I NAND Negierte UND-Verknüpfung 

I OR ODER-Verknüpfung 

I NOR Negierte ODER-Verknüpfung 

I XOR Exklusiv-ODER-Verknüpfung 

I XNOR Neg. Exklusiv-ODER-Verknüpfung (nur 93) 


Bei der Anwendung der logischen Operatoren auf Vektoren ist zu be- 
achten, daß die Vektoren gleiche Länge besitzen müssen und daß die 
Operation elementweise vorgenommen wird. Das Ergebnis erhält den 
Typ und die Indizierung des linken Operanden. 


Sequenzen von mehr als einem Operator sind nur für AND, OR und 
XOR möglich, da die Reihenfolge der Ausführung hier unerheblich ist. 
Bei den Operatoren NAND, NOR und XNOR ist dagegen durch Klam- 
merung die Ausführungsreihenfolge festzulegen. 


NOT (x AND y AND z) ; -- legal: NAND3 


(x NAND y) NAND z ; -- legal, aber kein NAND3 
x NAND y NAND z ; -- !!! jllegal 


Zu beachten ist weiterhin, daß der logische Operator NOT die hohe 
Priorität der "diversen Operatoren" besitzt. 
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6.1.2 Vergleichsoperatoren 


Operator| Funktion Typ linker | Typ rechter Typ 
Operand Operand Ergebnis 


Prüfung auf | alle mögl. gleicher Typ | vordef. Typ 
Gleichheit Typen außer | wie links boolean 
der Operan- | File-Typen 

den 


Prüfung auf | alle mögl. gleicher Typ | vordef. Typ 
Ungleichheit | Typen außer | wie links boolean 
der Operan- | File-Typen 

den 


Vergleich der| skal. Typen | gleicher Typ | vordef. Typ 
beiden Ope- | oder diskr. wie links boolean 
randen Vektoren 


Vergleich der| skal. Typen | gleicher Typ | vordef. Typ 
beiden Ope- | oder diskr. wie links boolean 
randen Vektoren 


Vergleich der| skal. Typen |gleicher Typ | vordef. Typ 
beiden Ope- | oder diskr. wie links boolean 
randen Vektoren 


Vergleich der| skal. Typen | gleicher Typ | vordef. Typ 
” beiden Ope- | oder diskr. wie links boolean 
randen Vektoren 


Als diskrete Vektoren werden in der obigen Tabelle die eindimensio- 
nalen Feldtypen bezeichnet, die als Elementtyp einen diskreten Typ 
(ganzzahliger Typ oder Aufzähltyp) besitzen. 


Der Gleichheitsoperator für zusammengesetzte Typen (Felder, Re- 
cords) liefert den Wert true zurück, falls jedes Element des linken 
Operanden ein entsprechendes Element im rechten Operanden besitzt 
(und umgekehrt) und falls alle entsprechenden Elemente im Wert 
übereinstimmen. Ansonsten wird der Wert false zurückgeliefert. 
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Entsprechendes gilt für den Ungleichheitsoperator mit vertauschtem 
Ergebnis. 


Beim Arbeiten mit Fließkommazahlen ist darauf zu achten, daß hier 
die Darstellungs- und Rechengenauigkeit der Hardware in das Ergeb- 
nis einfließt. Auf exakte Gleichheit sollte deshalb nie geprüft werden, 
vielmehr ist die Angabe eines Toleranzbereichs sinnvoll, wie sie etwa in 
der folgenden Art erfolgen kann: 


PROCESS 

VARIABLE xyz : real; 
BEGIN 
IF (xyz = 0.05) THEN -- schlechter Stil 


END IF; 


IF ABS (xyz - 0.05) <= 0.000001 THEN -- besserer Stil 


END IF; 


END PROCESS; 


Die Wirkung von Vergleichsoperatoren ist bei den diskreten Vektoren 
als Operanden folgendermaßen zu verstehen: Die Operation ">" z.B. 
liefert den Wert true zurück, falls gilt: 


I der linke Operand ist kein leerer Vektor, der rechte Operand ist 
leer. 


I im anderen Fall (kein leerer rechter Operand) muß gelten: 


O das am weitesten links stehende Element des linken Ope- 
randen ist "größer als" das am weitesten links stehende Ele- 
ment des rechten Operanden. 


O falls die beiden am weitesten links stehenden Elemente der 
beiden Operanden gleich sind, wird der Restvektor in glei- 
cher Weise untersucht. 

Die Operation ">=" bedeutet, daß entweder der Fall ">" oder der Fall 


=" zutrifft. Ein entsprechend komplementäres Verhalten zeigen die 
Operatoren "<" und "<=". 
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6.1.3 Arithmetische Operatoren 


6.1.3.1  Addierende Operatoren 


Operator| Funktion Typ linker | Typ rechter Typ 
Operand Operand Ergebnis 
+ Addition jeder nume- |gleicher Typ | gleicher Typ 
rische Typ wie links wie links 
Subtraktion |jeder nume- | gleicher Typ | gleicher Typ 
rische Typ wie links wie links 


Zusammen- | jeder gleicher Typ | gleicher Typ 
binden Vektortyp von Vektor |von Vektor 
wie links wie links 


jeder Element vom | gleicher Typ 
Vektortyp Typ wie Vek- | von Vektor 
tor links wie links 


Element vom | jeder gleicher Typ 
Typ wie Vek-| Vektortyp von Vektor 
tor rechts wie rechts 


jeder gleicher Typ | gleicher Typ 

Elementtyp | wie links von Vektor 
wie Element 
links 


Für den "&"-Operator, das Zusammenbinden von Operanden (im Eng- 
lischen "concatenation" genannt), gibt es verschiedene Arten von Ope- 
randenkombinationen: 


m) beide Operanden sind Einzelelemente gleichen Typs, 


7 ein Operand ist ein Vektor (eindimensionales Feld), der andere 
ein Einzelelement vom Typ der Vektorelemente, 


m) beide Operanden sind Vektoren gleichen Typs. 
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Das Ergebnis wird auf jeden Fall ein Vektor mit dem Elementtyp wie 
die Operanden selbst sein. Die Indizierung des Ergebnisses entspricht 
der vom linken Operanden fortgeführten Indizierung; Einzelelemente 
werden dabei als Vektor mit der Länge 1 angesehen. 


Die Fortsetzung der Indizierung des linken Vektors kann allerdings zu 
unerwarteten oder verbotenen Bereichsgrenzen führen. Mit Yg93 wurde 
deshalb folgende Vereinbarung getroffen: 


I Sind beide Operanden abfallend indiziert (DOWNTO), so haben 
rechter Operand und Ergebnis den gleichen rechten Index, 


I sind beide Operanden steigend indiziert (TO), so haben linker 
Operand und Ergebnis den gleichen linken Index. 


6.1.3.2 Signum-ÖOperatoren 


Signum-Operatoren dienen zur Festlegung des Vorzeichens von Ob- 
jekten numerischen Typs. 


Operator| Funktion Typ linker | Typ rechter Typ 
Operand Operand Ergebnis 


+ Identität jeder nume- | gleicher Typ 
rische Typ wie Operand 
Negation jeder nume- |gleicher Typ 
rische Typ wie Operand 
Die Signum-Operatoren dürfen ungeklammert nicht in Kombination 


mit multiplizierenden, addierenden und diversen Operatoren stehen 
(z.B. " A/ (-B) " anstelle des unerlaubten Ausdrucks " A/-B "). 
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6.1.3.3  Multiplizierende Operatoren 


Operator| Funktion Typ linker | Typ rechter Typ 
Operand Operand Ergebnis 


Multipli- jeder ganz- |gleicher Typ | gleicher Typ 
kation zahlige Typ | wie links wie links 


jeder Fließ- |gleicher Typ | gleicher Typ 
komma-Typ | wie links wie links 


jeder physi- |vordef. Typ | gleicher Typ 
kalische Typ |integer wie links 


jeder physi- |vordef. Typ | gleicher Typ 
kalische Typ | real wie links 


vordef. Typ |jeder physi- | gleicher Typ 
integer kalische Typ | wie rechts 


vordef. Typ |jeder physi- | gleicher Typ 
real kalische Typ | wie rechts 


Division jeder ganz- |gleicher Typ | gleicher Typ 
zahlige Typ | wie links wie links 


jeder Fließ- |gleicher Typ | gleicher Typ 
komma-Typ | wie links wie links 


jeder physi- |vordef. Typ | gleicher Typ 
kalische Typ |integer wie links 


jeder physi- |vordef. Typ | gleicher Typ 
kalische Typ | real wie links 


jeder physi- | gleicher Typ | vordef. Typ 
kalische Typ | wie links integer 


Modulo- jeder ganz- | gleicher Typ | gleicher Typ 
Operator zahlige Typ | wie links wie links 


Remainder- |jeder ganz- | gleicher Typ | gleicher Typ 
Operator zahlige Typ | wie links wie links 
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Der Remainder-Operator (a REM b) berechnet den Rest bei einer In- 
tegerdivision, so daß gilt: a = (a/b)*b + (a REM b) 
(a REM b) hat das Vorzeichen von a und einen absoluten Wert, der 


kleiner als der absolute Wert von b ist. 


Der Modulo-Operator (a MOD b) berechnet den Rest bei einer In- 
tegerdivision, so daß gilt: a = int_value*b + (a MOD b) 


(a MOD b) hat das Vorzeichen von b und einen absoluten Wert, der 
kleiner als der absolute Wert von b ist. 


6.1.3.4 Diverse Operatoren 


Die sog. "diversen Operatoren" besitzen die höchste Priorität bei der 
Abarbeitung. Der Vollständigkeit halber soll hier auch der logische 
Operator "NOT" nochmals erwähnt werden, der aufgrund der Priorität 
zu dieser Gruppe gehört. Weitere Operatoren dieser Gruppe sind: 


Operator | Funktion Typ linker Typ rechter |Typ 
Operand Operand Ergebnis 


Exponen- jeder ganz- |vordef. Typ | gleicher Typ 
tiation zahlige Typ |integer wie links 


jeder Fließ- |vordef. Typ | gleicher Typ 
komma-Typ |integer wie links 


Absolutwert- jeder nume- | gleicher Typ 
bildung rische Typ wie Operand 


6.1.4 Schiebe- und Rotieroperatoren Yg3 


Mit 7/93 wurden neben dem negierten Exklusiv-ODER weitere Opera- 
toren in den Sprachumfang aufgenommen. Es handelt sich um sechs 
Schiebe- und Rotieroperatoren, die auf Vektoren angewandt werden. 
Als linker Operand steht der Vektor selbst, als rechter Operand steht 
jeweils ein Integerwert, um dessen Wert der Vektorinhalt verschoben 
bzw. rotiert wird. Die Elemente des Vektors müssen vom Typ bit 
oder boolean sein. 
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Schiebe 
logisch links 


Schiebe 
logisch rechts 


Schiebe 
arithmetisch 
links 


Schiebe 
arithmetisch 
rechts 


Rotiere links 


Rotiere rechts 


Vektor, Ele- 


mente: bit, 


boolean 


Vektor, Ele- 


mente: bit, 


boolean 


Vektor, Ele- 


mente: bit, 


boolean 


Vektor, Ele- 


mente: bit, 


boolean 


Vektor, Ele- 


mente: bit, 


boolean 


Vektor, Ele- 


mente: bit, 


boolean 


6 Verhaltensmodellierung 


Operator| Funktion Typ linker | Typ rechter Typ 
Operand Operand Ergebnis 


vordef. Typ 
integer 


vordef. Typ 
integer 


vordef. Typ 
integer 


vordef. Typ 
integer 


vordef. Typ 
integer 


vordef. Typ 
integer 


gleicher Typ 
wie links 


gleicher Typ 
wie links 


gleicher Typ 
wie links 


gleicher Typ 
wie links 


gleicher Typ 
wie links 


gleicher Typ 
wie links 


Bei "logischen Schiebeoperationen" um eine Stelle geht jeweils das lin- 
ke bzw. rechte Vektorelement verloren. Auf der gegenüberliegenden 
Seite wird der Vektor mit dem lnitialisierungswert des Basistyps aufge- 
füllt. Bei "arithmetischen Schiebeoperationen" wird hierzu das letzte 
Vektorelement dupliziert. Bei mehrfachen Schiebe- oder Rotieropera- 
tionen wird dies entsprechend dem rechten Operanden wiederholt. Ne- 
gative rechte Operanden entsprechen dem gegensätzlichen Operator 
mit dem Absolutwert des rechten Operanden ("b ROL -4" entspricht 
"b ROR 4"). 
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Abb. B-11 verdeutlicht diese Operationen: 


rıLr LT LI ıInD LU LT LTD 1 _base_type 
SLL verloren "LEFT 
| BEE DE BE 5) BER To BE 5 N 5) HER 53 HER 5) BER | 
base_type ‚71,07 1,0 1,07 1,0 1,0 1,0 1,01 verlerän 
SRL LEFTTO ILL AI LI Ic Acc 
TIL UDIDILDUDL0 
SLA verloren 
LIU III [N NIIT 
In, 101,01, 1,01 
SRA verloren 
[I ı It [Ic cc 
IL LO LM IMDLNDLNLUN 1 
ROL L-ı LI LI [LI L[LıL DD 
r7,071,0 1,0710 1,0° 1,0 1,0 1 
ROR [I Lt J [I cJ [IS IS IS 
Abb. B-11: Schiebe- und Rotieroperatoren von 93 


6.2 Attribute 
Im folgenden sind die vordefinierten Attribute mit ihrer Funktion auf- 


gelistet. Sie werden nach dem Prefix unterschieden, auf das sie ange- 
wandt werden. 


6.2.1 Typbezogene Attribute 


Typbezogene Attribute liefern Informationen zu diskreten Daten- 
typen, wie z.B. Werte von bestimmten Elementen bei Aufzähltypen. 
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t'BASE liefert den Basistyp des Prefixtyps t (nur in Ver- 
bindung mit nachfolgendem weiteren Attribut 
möglich) 


| 


t'POS (x) liefert die Position (integer-Index) des 
Elements x im Prefixtyp t 

t'VAL(y) liefert den Wert des Elements an Position y im 
Prefixtyp t (y istinteger) 

liefert den Nachfolger von x im Prefixtyp t 


) 
liefert den Vorgänger von x im Prefixtyp t 
liefert das Element links von x im Prefixtyp t 


t 'RIGHTOF (x) | liefert das Element rechts von x im Prefixtyp t 


Im neuen Standard (/g93) wurden einige weitere typbezogene Attri- 
bute aufgenommen: 


t 'ASCENDING |liefert true, falls der Typ t eine steigende Indi- 
zierung besitzt, ansonsten false 
' 


t'IMAGE (x) konvertiert den Wert x in eine Zeichenkette t 
x) 


t'VALUE ( konvertiert die Zeichenkette x in einen Wert des 
Typs t 
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Die oben beschriebenen typbezogenen Attribute sollen nun anhand 
einiger Beispiele erläutert werden: 


asc_int IS RANGE 2 TO 8; -- steigend 

desc_int IS RANGE 8 DOWNTO 2; -- fallend 

colors IS (white, red, yellow, green, blue); 
SUBTYPE signal_colors IS colors RANGE (red TO green); 
VARIABLE a : integer := 0; 
VARIABLE b : colors := blue; 
VARIABLE c : boolean := true; 

BEGIN 
a := asc_int'LEFT; Ergebnis: 
asc_int'RIGHT; Ergebnis: 
asc_int'LOW; Ergebnis: 
asc_int'HIGH; Ergebnis: 
desc_int'LEFT; Ergebnis: 
desc_int 'RIGHT; Ergebnis: 
desc_int'LOW; Ergebnis: 
desc_int'HIGH; Ergebnis: 
asc_int'PRED (7); Ergebnis: 
asc_int'SUCC (4); Ergebnis: 
asc_int'LEFTOF (7); Ergebnis: 
asc_int 'RIGHTOF (4); Ergebnis: 
desc_int'PRED (7); Ergebnis: 
desc_int'S n Ergebnis: 
desc_int'] ; Ergebnis: 
desc_int 'RIGHTOF (4); Ergebnis: 
asc_int'PRED (2); I! illegal: kein Vorgaenger 
asc_int'SUCC (8); !ı illegal: kein Nachfolger 
asc_int'LEFTOF (15); ıı jllegal: falscher Index 
signal_colors'RIGHT; -- Ergebnis: green 
signal_colors'BASE'RIGHT; -- Ergebnis: blue 
colors'LEFTOF (red); Ergebnis: white 
colors'RIGHTOF (red); Ergebnis: yellow 

= colors'POS (red); Ergebnis: 1 (Aufzaehltypen 

werden von 0 an indiziert) 

= colors'VAL(2); Ergebnis: yellow 
asc_int 'ASCENDING; Ergebnis: true I!!! VHDL'93 

= desc_int 'ASCENDING; Ergebnis: false !!! VHDL'93 

= colors'VALUE ("red "); Ergebnis: red (VHDL'93) 


WOoUANAUNAUNOND ND OO ND N 
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b::: 
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END PROCESS; 


Das Ergebnis der Attribute RIGHT/LEFT und RIGHTOF/LEFTOF 
hängt also von der Indizierungsrichtung ab. Bei fallender Indizierung 
sind die Ergebnisse identisch mit den Ergebnissen von LOW/HIGH 
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und PRED/SUCC. Die Aufzähltypen (z.B. colors) besitzen implizit 
eine steigende Indizierung, so daß beispielsweise RIGHTOF dem 
Attribut SUCC entspricht. 


6.2.2 Feldbezogene Attribute 


Bei den feldbezogenen Attributen finden sich viele typbezogene 
Attribute wieder. Sie werden hier auf eingeschränkte Typen von Fel- 
dern und auf konkrete Objekte angewandt. 


a'LEFT [(n)] liefert die linke Grenze der n-ten Dimension 
des Feldes a 

a'RIGHT [(n)] liefert die rechte Grenze der n-ten Dimension 
des Feldes a 

a'LOW [(n)] liefert die untere Grenze der n-ten Dimension 
des Feldes a 


a'HIGH [(n)] liefert die obere Grenze der n-ten Dimension 
des Feldes a 

a'LENGTH [(n)] |liefert die Bereichslänge der n-ten Dimension 
des Feldes a 

a'RANGE [(n)] liefert den Bereich der n-ten Dimension des 
Feldes a 

a'REVERSE liefert den Bereich der n-ten Dimension des 

_RANGE [(n)] Feldes a in umgekehrter Reihenfolge 

In Yg93 wurde das Attribut ASCENDING ergänzt: 


a'ASCENDING liefert true, falls das Feld a in der n-ten 
[(n)] Dimension eine steigende Indizierung besitzt 


© G. Lehmann/B. Wunder/M. Selz 133 


B Die Sprache VHDL 


Die feldbezogenen Attribute beziehen sich immer auf eine Indizie- 
rung. Diese ist bei eindimensionalen Feldern (Vektoren) eindeutig. 
Die Angabe der Dimension (n), auf die das Attribut angewandt wer- 
den soll, ist daher nur bei mehrdimensionalen Feldern relevant. Wird 
sie weggelassen, so wird das Attribut immer auf die erste Dimension 
angewandt. 


ESS 

YPE asc_vec IS ARRAY (1 TO 5) OF integer; 

YPE int_matrix IS ARRAY (0 TO 4, 9 DOWNTO 0) OF integer; 
CONSTANT mask : asc_vec := (OTHERS => 0); 
VARIABLE arl : int_matrix; 

VARIABLI : integer := 0; 


Ra 
VARIABLE b : boolean; 
EGIN 
a := EFT; Ergebnis: 


trix'HIGH (2); Ergebnis: 
EFT (1); Ergebnis: 
trix'LEFT (1); Ergebnis: 
EFT (2); Ergebnis: 
‚ENGTH (1); Ergebnis: 
‚ENGTH (2); Ergebnis: 
= arl'ASCENDING (2); VHDL'93, 1 
= arl'ASCENDING (1); VHDL'93, 1 
WAIT; 
END PROCESS; 


con om m m m m 


6.2.3 Signalbezogene Attribute 


Folgende Attribute werden auf konkrete Objekte der Klasse Signal an- 
gewandt: 


S'DELAYED [(t)] | liefert ein auf s basierendes Signal, welches 
um eine Zeit t (default: 1 Delta) verzögert ist 


s'STABLE [(t)] liefert true, falls das Signal s eine Zeit t 
(default: 1 Delta) ohne Ereignis war, sonst 
false 
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s'QUIET [(t)] liefert true, falls das Signal s eine Zeit t 
(default: 1 Delta) nicht aktiv war, sonst 
false 

s'TRANSACTION liefert ein Signal vom Typ bit, welches bei 
jedem Simulationszyklus wechselt, in dem das 
Signal s aktiv ist 

s'EVENT liefert true, falls beim Signal s während des 
aktuellen Simulationszyklus ein Ereignis auf- 
tritt, sonst false 


s'ACTIVE liefert true, falls das Signal s während des 
aktuellen Simulationszyklus aktiv ist, sonst 
false 

s'LAST_EVENT liefert die Zeitdifferenz vom aktuellen Simu- 
lationszeitpunkt zum letzten Ereignis des 
Signals s 

s'LAST_ACTIVE liefert die Zeitdifferenz vom aktuellen Simu- 
lationszeitpunkt zum letzten aktiven Zeit- 
punkt des Signals s 

s'LAST_VALUE liefert den Wert des Signals s vor dem letzten 
Ereignis 


Einige signalbezogene Attribute können mit einem Zeitparameter (t) 
versehen werden, um z.B. beim Attribut DELAYED ein um t ver- 
zögertes Signal zu erhalten. Wird kein Parameter angegeben, so gilt als 
Defaultwert die minimale Zeit "Delta" (siehe Kapitel 8). Das Signal 
"sigl'DELAYED" ändert z.B. immer ein Delta später seinen Wert als 
das Signal "sig1". 


Die Zusammenhänge bei signalbezogenen Attributen sollen in einem 
kleinen Beispiel verdeutlicht werden. Gegeben sei folgender Signal- 
verlauf: 
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ER 7ns, 
ER 24 ns, 
ER 30 ns, 


WAIT; 


END PROCI 


Die Verläufe der verschiedenen Attribute des Signals sig_a über der 
Zeit werden in Abb. B-12 dargestellt. 


= sig_a 
9 I_ 


sig_a” 
DELAYED (c/2) 


A | | 1 | \ TRANSACTION 
true . , 2 
ACTIVI 

false | | | | | | | | | sig_a’AC 


sig_a ‘QUIET (c) 


ke 


5 


true sig_a ‘EVEN 


sig_a 'STABLE (c) 


false L_ | | i | i | 
44444444444 444 444 4 44 1 / [ns] 
0 10 20 30 40 


Abb. B-12: Signalbezogene Attribute 
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Mit /93 sind weitere signalbezogene Attribute verfügbar: 


s'DRIVING liefert false, falls der Treiber des Signals s 
gerade abgeschaltet ("disconnected") ist, sonst 


true (siehe Kapitel 9) 


s'DRIVING liefert den aktuellen Wert des Treibers für das 
_VALUE Signal s (siehe Kapitel 9) 


Die beiden letztgenannten Attribute können in Prozessen, die dem Si- 
gnal s einen Wert zuweisen, oder in Prozeduren, die s als OUT-, 
BUFFER- oder INOUT-Signal besitzen, verwendet werden. Sie sind 
sinnvoll, um Signale vor der Behandlung mit Auflösungsfunktionen 
oder Ports vom Modus OUT lesen zu können. 


Anwendungen der signalbezogenen Attribute finden sich in den Ab- 
schnitten über Signalzuweisungen und den VHDL-Beispielen. 


6.2.4 Blockbezogene Attribute Yg7 


Die folgenden Attribute sind nur in der alten Norm (V g7) verfügbar. 
Mit der Überarbeitung der Norm wurden beide Attribute gestrichen! 


b'BEHAVIOR liefert true, falls der Block (oder die Archi- 
tektur) b eine reine Verhaltensbeschreibung 
enthält (d.h. falls keine Komponentenin- 
stantilerungen enthalten sind), sonst false 


b'STRUCTURE liefert true, falls der Block (oder die Arch- 
itektur) b eine rein strukturale Beschreibung 
enthält (d.h. falls keine Signalzuweisungen 
enthalten sind), sonst false 
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6.2.5 Allgemeine Attribute Y'93 


In Y93 sind auch Attribute verfügbar, die den Namen oder den Pfad 
von Objekten in der Hierarchie eines VHDL-Modells ermitteln. Dies 
kann zur Fehlersuche im Zusammenspiel mit der ASSERT-Anweisung 
nützlich sein. 


Diese allgemeinen Attribute lassen sich nicht nur auf Objekte anwen- 
den, sondern meistens auch auf alle VHDL-Einheiten (vgl. Gruppen), 
die einen Namen besitzen: 


e'SIMPLE_NAME liefert den Namen der Einheit e als Zeichen- 
kette (string) in Kleinbuchstaben 


e'PATH_NAME liefert den Pfad der Einheit e innerhalb des 
Modells als Zeichenkette in Kleinbuchstaben. 
e'INSTANCE_NAME | wie PATH_NAME, zusätzlich mit Informa- 


tionen über Konfigurationen bei Komponen- 
ten 
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6.3  Signalzuweisungen und 
Verzögerungsmodelle 


Die wohl wichtigste Anweisung in VHDL ist die Zuweisung von neuen 
Werten an Signale. Signale dienen als Informationsträger innerhalb ei- 
nes VHDL-Modells und zur Kommunikation mit dessen Umwelt. 


6.3.1 Syntax 


Signalzuweisungen können nebenläufig sein oder als sequentielle An- 
weisungen innerhalb von Prozessen, Funktionen oder Prozeduren ste- 
hen. 


Das Ziel der Zuweisung (sig_name) kann ein einzelnes Signal oder 
ein Teil eines Vektors (slice), bestehend aus mehreren Signalen sein. 
Als zuzuweisendes Argument (value_expr) kann bei Signalzu- 
weisungen wieder ein Signal gleichen Typs oder ein beliebiger Aus- 
druck, der einen Signal typkonformen Wert liefert, stehen. Der neue 
Signalwert kann einerseits nur um ein Delta verzögert zugewiesen 
werden, indem der optionale AFTER-Teil der Signalzuweisung weg- 
gelassen wird oder indem eine Null-Verzögerung angegeben wird 
("AFTER O ns"). Andererseits ist die explizite Angabe einer Verzö- 
gerungszeit über das Schlüsselwort AFTER und eine nachfolgende 
Zeitangabe (time_expr) möglich. In VHDL stehen dazu zwei ver- 
schiedene Verzögerungsmodelle zur Verfügung, die hier erläutert wer- 
den sollen. 


Die Grundsyntax für Signalzuweisungen lautet: 


sig_name <= [TRANSPORT] 
value_expr_1 [AFTER time_expr_1] 
{, value_expr_n AFTER time_expr_n } ; 


Das Schlüsselwort TRANSPORT dient zur Kennzeichnung des "Trans- 
port"-Verzögerungsmodells. Falls das Schlüsselwort fehlt, wird das 
"Inertial"-Verzögerungsmodell angewandt. Beiden Modellen gemein 
ist der sog. "Preemption-Mechanismus". 
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6.3.2 Ereignisliste 


Die Auswirkungen dieses Mechanismus und die Verzögerungsmodelle 
können am besten durch eine graphische Darstellung der Ereignisliste 
erläutert werden. 


Die Ereignisliste ("waveform" oder "event queue") enthält alle zukünf- 
tigen Signalwechsel in einem Simulationslauf. Signalwechsel, die mit 
Verzögerungszeiten behaftet sind, werden an die entsprechende Stelle 
in dieser Liste eingetragen. Bei der Simulation wird diese Ereignisliste 
abgearbeitet, d.h. die dort vermerkten Signalwechsel ausgeführt und 
deren Auswirkungen berechnet, was in aller Regel neue Einträge in der 
Ereignisliste bewirkt. 


Folgende, zum Zeitnullpunkt durchgeführte Signalzuweisung, ent- 
spricht der graphischen Ereignisliste der Abb. B-13. 


sig_a <= '1' AFTER 2 ns, '0O' AFTER 5 ns, 'I' AR 


'1' AFTER 12 ns, '0' AFTER 15 ns, '1' AR 


Abb. B-13: Ereignisliste für das Signal sig_a 


Es sei an dieser Stelle auf einige Begriffe aus der "VHDL-Welt" hinge- 
wiesen, die im Zusammenhang mit den Signalzuweisungen stehen. Die 
einzelnen Einträge in der Ereignisliste, die jeweils aus einer Zeit- und 
einer Wertangabe bestehen, werden als Transaktion ("transaction") be- 
zeichnet. Ein Ereignis ("event") auf einem Signal tritt auf, wenn ein 
Signal gerade seinen Wert ändert. Dagegen ist ein Signal auch aktiv 
("active"), falls ihm gerade ein Wert zugewiesen wird, unabhängig da- 
von, ob sich dadurch der Signalwert ändert oder nicht. In Abb. B-13 
sind also zu den Zeitpunkten 2, 5, 10, 12, 15 und 17 ns Transaktionen 
festgelegt. Ein Ereignis auf dem Signal würde zum Zeitpunkt 2, 5, 10, 
15 und 17 ns auftreten, sofern sich die Ereignisliste zwischenzeitlich 
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nicht ändert. Aktiv wäre das Signal dagegen an allen Ereigniszeit- 
punkten und zusätzlich bei 12 ns. 


6.3.3 Preemption-Mechanismus 


"Preemption" bezeichnet das Entfernen von geplanten Transaktionen 
aus der Ereignisliste. Der Premption-Mechanismus wird bei jeder neu- 
en Signalzuweisung angewandt. Welche Transaktionen dabei gelöscht 
werden, hängt vom bei der Signalzuweisung verwendeten Verzöge- 
rungsmodell ab. 


Für VHDL-Simulatoren ist der Preemption-Mechanismus durch die 
VHDL-Norm vorgeschrieben. Herkömmliche Digitalsimulatoren ar- 
beiten oft nicht nach diesem Mechanismus. 


6.3.4 "Transport"-Verzögerungsmodell 


Bei diesem Verzögerungsmodell von VHDL werden alle Transaktio- 
nen gelöscht, die nach einem neuen Signalwert oder gleichzeitig mit 
diesem auftreten. Es führt dazu, daß eine Signalzuweisung "sig_a <= 
TRANSPORT '1' AFTER 11ns;" die zum Zeitpunkt 2 ns durch- 
geführt wird, alle diesem neuen Eintrag bei 13 ns nachfolgenden oder 
zur gleichen Zeit stattfindenden Einträge aus der Ereignisliste löscht. 
Es ergibt sich damit eine neue Ereignisliste für das Signal sig_a: 


1 vo 1 171 
| a ee 
(0) 5 10 15 t/ns 


Abb. B-14: Neue Ereignisliste für das Signal sig_a nach dem 
"Transport"-Verzögerungsmodell 
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6.3.5 "Inertial"-Verzögerungsmodell 


Beim "Inertial"-Verzögerungsmodell wird zusätzlich zum "Transport"- 
Verzögerungsmodell folgende Regel angewandt: 


® Markiere die unmittelbar vor dem neuen Eintrag stattfindende 
Transaktion, falls sie den gleichen Wert besitzt. 


® Markiere die aktuelle und die neue Transaktion. 
® Lösche alle nicht markierten Transaktionen. 


Diese Vorgehensweise führt dazu, daß nur diejenigen Impulse, die eine 
längere (oder gleichlange) Dauer als die angegebene Verzögerungs- 
zeit besitzen, auch tatsächlich auftreten. Das Inertial-Verzögerungs- 
modell ist immer dann gültig, wenn in der Signalzuweisung nicht das 
Schlüsselwort TRANSPORT auftritt. 


Eine Zuweisung "sig_a <= '1' AFTER 11ns;" die zum Zeit- 
punkt 2 ns durchgeführt wird, führt aufgrund des Inertial-Modells auf 
folgende Ereignisliste für das Signal sig_a: 


ı PP Pi PP 


0 5 10 15 t/ns 


Abb. B-15: Neue Ereignisliste für das Signal sig_a nach dem 
"Inertial"-Verzögerungsmodell 


6.3.6 "Reject-Inertial"-Verzögerungsmodell Y93 


Bei der Zuweisung "sig_b <= sig_c AFTER 3 ns;" wird das 
"Inertial"-Verzögerungsmodell angewandt. Eine wesentliche Konse- 
quenz ist, daß jeder Impuls des Signals sig_c, der kürzer als die an- 
gegebene Verzögerungszeit von 3 ns ist, unterdrückt ("rejected") wird. 


Dies ist bei manchen Komponenten sicherlich sinnvoll, die kurze Im- 
pulse ("Spikes") unterdrücken oder herausfiltern. Oft entspricht der 
Grenzwert dieser Impulsdauer aber nicht der Verzögerungszeit der 
Komponente. In Vg93 wurde deshalb ein drittes Verzögerungsmodell 
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eingeführt, das eine von der Verzögerungszeit unabhängige Zeitan- 
gabe für eine minimal übertragene Impulsdauer (rej_time_expr) 
gestattet. Es hat folgende Syntax: 


sig_name <= [[REJECT rej_time_expr] INERTIAL] 
value_expr_1 [AFTER time_expr_1l] 
{, value_expr_n AFTER time_expr_n er 


Um eine deutlichere Kennzeichnung des (Default-) "Inertial"-Verzö- 
gerungsmodells zu erzielen, ist das Schlüsselwort INERTIAL nun 
auch ohne REJECT optional. Die Obergrenze für die Impulsdauer 
(rej_time_expr) darf bei diesem Verzögerungsmodell nicht 
größer als die erste Verzögerungszeit (time_expr_1) sein. 


Folgendes Beispiel zeigt die Auswirkungen der drei Verzögerungsmo- 
delle anhand von verschieden breiten Impulsen des Signals sig_s: 


ER 5 
ER 13 
ER 20 
ER 26 


<= TRANSPORT ER ins, 
ER 10 ns, 
ER 18 ns, 
ER 25 ns, 


A 
Ar 
Ar 
A 


RANSPORT sig_s AFTER 3 ns; 
sig_s ER 3 ns; 
ECT 2 ns INERTIAL sig_s AFTER 3 ns; -- ! VHDL'93 


| I |] | 5 sig_s 
I | |] I|_ set 
I | sig_i 
I | 3] sig_r 


0 5 10 15 20 25 30 t/ns 


Abb. B-16: Signalverläufe bei unterschiedlichen 
Verzögerungsmodellen 
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Abb. B-16 zeigt folgende Effekte: Bei Anwendung des "Transport"- 
Verzögerungsmodells (sig_t) wird das Quellsignal (sig_s) unver- 
ändert in seiner Form um 3 ns verzögert. Beim "Inertial"-Verzöge- 
rungsmodell (sig_i) werden Impulse, die kürzer als die Verzöge- 
rungszeit sind, unterdrückt. Das "Reject-Inertial"-Modell schließlich 
unterdrückt nur Impulse, die kürzer als die nach dem Schlüsselwort 
REJECT spezifizierte Zeit von 2 ns sind. 


Weitere, interessante Effekte treten auf, wenn unterschiedliche Verzö- 
gerungszeiten für steigende und fallende Signalflanken spezifiziert 
werden. Diesen Fall beleuchtet folgendes Beispiel: 


tpd_Ih=5ns 
tpd_hl=3ns tpd_Ih=3ns 
tpd_hl=4ns 


Abb. B-17: Flankenabhängige Laufzeiten 


Wird für beide Gatter das "Transport"-Verzögerungsmodell verwendet, 
so passiert (durch den "Preemption"-Mechanismus) kein positiver Im- 
puls des Signals a, der kürzer als 2 ns ist, das AND-Gatter. Impulse, 
die länger als 2 ns sind, werden um 2 ns verkürzt. Das zweite Gatter in- 
vertiert den positiven Impuls und verkürzt ihn wiederum um 1 ns. Bei 
der gegebenen Beschaltung gelangen also positive Impulse am 
Eingang a nur an den Ausgang y, wenn ihre Dauer größer als 3 ns ist. 


Noch komplizierter wird der Fall, wenn das "Inertial"-Verzögerungs- 
modell verwendet wird. Positive Impulse an a werden um 2 ns verkürzt 
und erst ab 5 ns Dauer weitergegeben. Das zweite Gatter läßt positive 
Impulse nur passieren, wenn sie länger als 4 ns sind. Sie werden dabei 
um Ins verkürzt. Der kürzeste, nicht unterdrückte positive Impuls an 
a muß demnach 6 ns lang sein und erscheint am Ausgang mit einer 
Dauer von nur 3 ns. 


Dem Leser wird empfohlen, sich diese Situation mit Hilfe von Ereig- 
nislisten zu verdeutlichen. Außerdem kann untersucht werden, wie sich 
der Ausgang bei negativen Impulsen am Eingang a verhält. 
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6.4 Nebenläufige Anweisungen 


Nebenläufige Anweisungen enthalten optional innerhalb der Anwei- 
sung ein sog. Label. Dieses Label kann auch als Name der Anweisung 
interpretiert werden. Er dient zum späteren Referenzieren der spezifi- 
schen Anweisung (z.B. bei der Konfiguration eines strukturalen Mo- 
dells) oder auch für benutzerdefinierte Attribute. 


Sequentielle Anweisungen dürfen hingegen nach Yg7 im allgemeinen 
keine Labels tragen. Erst mit Vg3 können Labels für alle Anweisun- 
gen (nebenläufig und sequentiell) vergeben werden. 


6.4.1 Signalzuweisungen (normal und bedingt) 


Im Falle von nebenläufigen Signalzuweisungen lautet die Syntax der 
nicht-bedingter Zuweisung: 


[assignment_label :] sig_name <= [TRANSPORT] 
value_expr_1l [AFTER time_expr_1l] 
{ , value_expr_n AFTER time_expr_n } ; 


Werden bei der Signalzuweisung mehrere Werte angegeben, so müssen 
diese in zeitlich aufsteigender Reihenfolge angeordnet sein. 


Die erste Alternative bedingter Signalzuweisungen ("conditional si- 
gnal assignment") basiert auf mehreren Zuweisungsalternativen, die je- 
weils durch Bedingungen (condition) gesteuert werden. Dies ent- 
spricht also einer sequentiellen IF-ELSIF-ELSE-Struktur. Die Syn- 
tax des "conditional signal assignment" hat folgendes Aussehen: 


[assignment_label :] sig_name <= [TRANSPORT] 
{ value_expr_m [AFTER time_expr_m] 
{, value_expr_n AFTER time_expr_n } 
WHEN condition_m ELSE } 
value_expr_o [AFTER time_expr_o] 
{, value_expr_p AFTER time_expr_p }; 


Die zweite Alternative ("selected signal assignment") entspricht in ih- 
rem Verhalten der sequentiellen CASE-Anweisung. Sie basiert auf be- 
stimmten Alternativen (choice) eines Ausdruckes (expression) 
und hat folgendes Aussehen: 


© G. Lehmann/B. Wunder/M. Selz 145 


B Die Sprache VHDL 


[assignment_label :] WITH expression SELECT 
sig_name <= [TRANSPORT] 
{ value_expr_m [AFTER time_expr_m] 

{, value_expr_n AFTER time_expr_n} 
WHEN choice_m ,„ } 
value_expr_o [AFTER time_expr_o] 

{, value_expr_p AFTER time_expr_p} 
WHEN choice_o ; 


Werden mit den einzelnen Auswahlalternativen nicht alle möglichen 
Werte von expression abgefragt, so muß an Stelle von choice_o 
das Schlüsselwort OTHERS gesetzt werden, um die nicht explizit abge- 
fragten Werte zu erfassen. 


ARCHITECTURE behavioral OF signals IS 
SIGNAL sig_a, sig_b, sig_c : std_ulogic; 
EGIN 
nebenlaeufige Signalzuweisung mit TRANSPORT 
sig_a <= TRANSPORT '0', '1' AFTER 2 ns, 'Z' AF 


illegal: Werte nicht zeitlich aufsteigend 
sig_a <= TRANSPORT '0', 'Z' AFTER 3 ns, '1' AFTE 


-- "conditional signal assignment" (csa) 


csa: sig_b <= '1', '0' AFTER 2 ns WHEN sel = 
'0', '1' AFTER 3 ns WHEN sel 
‚Zr 


dem csa entsprechendes "selected signal assignment" (ssa) 
ssa: WITH sel SELECT 
sig_c <= '1'!, '0' AFTER 2 ns WHEN 1, 
'0', '1' AFTER 3 ns WHEN 2, 
'Zz' WHEN OTHERS; 
END behavioral; 


In vielen Fällen von nebenläufigen, bedingten Signalzuweisungen ist 
bei bestimmten Bedingungen kein Signalwechsel erforderlich. Die ein- 
zige Möglichkeit, dies mit der alten VHDL-Norm zu realisieren, liegt 
in der Zuweisung des Signals an sich selbst, wie es das Beispiel eines 
einfachen taktpegelgesteuerten Speicherbausteins (Latch) zeigen soll: 
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ENTITY latch IS 
PORT (d, cIk : 
END latch 


IN bit; 


q : BUFF 


r 


ARCHI 
BEGIN 
q <= dWwH 
END concurrent_1 


ECTUR 


" 


concurrent_1 OF latc 


ELS 


I 


q -- csa-Alternative 


r 


r 


ARCHIT 


ECTUR 


Fr 


concurrent_2 OF latch IS 


B 


EGIN 
WITH clk S 


q<=dW 
qW 


ECT 


Di 


EN 


-- ssa-Alternative 
1!" 


H 


EN OTH 


END concurrent_2 


r 


Diese Realisierungen haben jedoch beide den Nachteil, daß bei negati- 
ven Taktflanken unnötige Transaktionen des Signals erzeugt werden 
und durch den "Preemption"-Mechanismus möglicherweise Informa- 
tionen verloren gehen. 


Eine saubere Lösung des Problems bietet Yg3 mit dem Schlüsselwort 
UNAFFECTED. Es kann bei den bedingten Signalzuweisungen einge- 
setzt werden und erzeugt keine Transaktion auf dem Signal: 


ARCHIT 


ECTURE concurrent_3 OF latch IS I! nur VHDL'93 


B 


EGIN 


q<=dW 


EN clk = 


']'! 


q 


‚SE UNAFF 


ECT 


ECTUR 


Fr 


END concurrent_3 ; 


concurrent_4 OF latch IS 


I! nur VHDL'93 


IH clk S 


ECT 


q<=d 


EN 


Et, 


UNAFF 


EN OTH 


ERS ; 


END concurrent_4 
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6.4.2 Assertions 


Assertions dienen zur Überprüfung von Bedingungen und zur Aus- 
gabe von Warnungen bzw. Fehlermeldungen. Die Syntax lautet: 


[assert_label :] ASSERT condition 
[ REPORT "message_string"] 
[ SEVERITY severity_level] ; 


Diese Syntax wird folgendermaßen interpretiert: 


"Überprüfe, ob die Bedingung condition erfüllt ist; falls 
nicht, erzeuge die Meldung "message_string" und bre- 
che, abhängig von der Fehlerklasse severity_level, ge- 
gebenenfalls die Simulation ab." 


Eine Fehlermeldung mit evtl. weiteren Konsequenzen tritt also nur auf, 
falls die angegebene Bedingung (condition) den Wert false er- 
gibt. 

Ohne Angabe der Fehlermeldung wird der String "Assertion 


violation." ausgegeben. 


Die vier möglichen Fehlerklassen (entsprechend dem vordefinierten 
Aufzähltyp severity_level) haben folgende Bedeutung: 


I note dient zur Ausgabe von allgemeinen Informationen, 


I warning dient zur Anzeige von möglichen unerwünschten Be- 
dingungen, 

I error zeigt an, daß eine Aufgabe mit dem falschen Ergebnis 
abgeschlossen wurde, 


I failure zeigt an, daß eine Aufgabe nicht abgeschlossen wer- 
den konnte. 


Wird in der Anweisung keine Fehlerklasse angegeben, so wird sie mit 
der Klasse error versehen. Die Entscheidung, ab welcher Klasse die 
Simulation abgebrochen wird, legt man i.d.R. durch eine spezifische 
Simulatoreinstellung fest. 


Zwei Beispiele zur Anzeige eines (low-aktiven) Resetsignals und zur 
Prüfung auf definierten Pegel eines Signals sig_a vom Typ std_ 
ulogic lauten: 
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reset_check : ERT sig_reset /= '0' 
EPORT "Achtung: Reset ist aktiv !" 
EVERITY note ; 


ERT (now = 0 fs) OR (sig_a /= 'U') 
EPORT "sig_a ist nicht initialisiert !"; 


Im zweiten Beispiel wird die Ausgabe einer Fehlermeldung zum Zeit- 
nullpunkt unterdrückt. 


6.4.3 Prozesse 


Prozesse dienen als Umgebung für sequentielle, d.h. nacheinander ab- 
laufende Befehle. Sie werden also zur Modellierung prozeduraler Vor- 
gänge verwendet. Die Prozesse selbst gelten als nebenläufige An- 
weisung, d.h. existieren mehrere Prozesse innerhalb einer Architektur, 
so können sie gleichzeitig aktiv sein. Prozesse werden durch zwei ver- 
schiedene Möglichkeiten aktiviert und gestoppt, die sich gegenseitig 
ausschließen: 


I Durch eine Liste sensitiver Signale im Prozeß-Kopf: 
Prozesse dieser Art werden einmalig bei der Modell-Initialisie- 
rung komplett durchlaufen und zu späteren Zeitpunkten erst 
wieder aktiviert, wenn sich eines der Signale der "sensitivity list" 
ändert. Dann wird der Prozeß wieder bis zum Ende abgearbeitet, 
usw. 


m) Durch WAIT-Anweisungen: 
Bei der Modell-Initialisierung zum Zeitnullpunkt wird der Pro- 
zeß bis zur ersten WAIT-Anweisung abgearbeitet und erst wieder 
aktiviert, wenn die Bedingung der WAIT-Anweisung erfüllt ist 
oder die dort angegebene Zeit verstrichen ist (vgl. WAIT-Anwei- 
sung). 


Prozesse ohne WAIT-Anweisung und ohne "sensitivity list" sind übli- 
cherweise nicht sinnvoll, da diese Prozesse beim Simulationsstart auf- 
gerufen und dann ständig zyklisch durchlaufen werden ("Endlos- 
schleife"). 
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Prozesse bestehen aus einem Deklarations- und einem Anweisungsteil. 
Die Syntax der beiden Varianten lautet: 


[process_label :] PROCESS (sig_l1 {, sig_n}) 
-- Deklaration von: Typen und Unter- 
-- typen, Aliases, Konstanten, Files, 
-- Variablen, Unterprogrammen 
-- Definition von: Unterprogrammen, 
-- Attributen 
-- USE-Anweisungen 

BEGIN 
-- sequentielle Anweisungen ohne WAIT 


END PROCESS [process_label] ; 


[process_label :] PROCESS 
-- Deklarationsteil wie oben 


BEGIN 


- sequentielle Anweisungen 
WAIT ... ; -- mind. eine WAIT-Anweisung 
-- sequentielle Anweisungen 


END PROCESS [process_label] ; 


Während (herkömmliche) Variablen nur innerhalb eines Prozesses 
gültig und außerhalb nicht sichtbar sind, können Signale auch außer- 
halb eines Prozesses gelesen und mit neuem Wert versehen, d.h. be- 
schrieben werden. Sie können somit zur Kommunikation (Austausch 
von Informationen, gegenseitiges Aktivieren usw.) zwischen Prozessen 
verwendet werden. 


Ein wesentlicher Aspekt im Zusammenhang mit Prozessen ist das Zeit- 
verhalten, insbesondere der zeitliche Unterschied zwischen Variablen- 
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und Signalzuweisungen innerhalb eines Prozesses. Während Variab- 
lenwerte sofort bei der Abarbeitung der Anweisung zugewiesen wer- 
den, werden die neuen Werte von Signalen zunächst vorgemerkt und 
erst nach Abarbeitung aller aktiven Prozesse am Ende eines sog. Delta- 
Zyklus zugewiesen. Diese Problematik wird getrennt in Kapitel 8 be- 
handelt. 


Da sequentielle Anweisungen an dieser Stelle noch nicht behandelt 
wurden, wird für ausführliche Beispiele zu Prozessen auf die nachfol- 
genden Abschnitte verwiesen. An dieser Stelle wird deshalb nur ein 
kurzes Beispiel für ein D-Latch aufgeführt, das eine selbsterklärende 
IF-Struktur enthält: 


ARCHITECTURE sequential_1 OF latch IS 
BEGIN 
-- Aktivierung des Prozesses durch Ereignisse auf d oder clk 
q_assignment: PROCESS (d, clk) 

BEGIN 


IF clk = '1' THEN 
q<=d; 

END IF ; 

END PROCESS q_assignment ; 

END sequential_l ; 


Die Vereinheitlichung der Rahmensyntax in /'g3 führt zu einer optio- 
nalen Angabe des Schlüsselwortes IS: 


[process_label :] 
PROCESS [(sig_1 {, sig_n})] [IS] 


BEGIN 
END PROCESS [process_label] ; 
6.5 Sequentielle Anweisungen 
Wie bereits erwähnt, kann mit der Überarbeitung der VHDL-Norm 


(Y’93) jeder Anweisung, also auch den sequentiellen Anweisungen, ein 
Label zugeteilt werden. 
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6.5.1 Signalzuweisungen 


Die Syntax für sequentielle Signalzuweisungen lautet: 


sig_name <= [TRANSPORT] 
value_expr_l1l [AFTER time_expr_1l] 
{ , value_expr_n AFTER time_expr_n } ; 


Die einzelnen Signalwerte müssen dabei in zeitlich aufsteigender Rei- 
henfolge angeordnet sein. 


Bedingte Signalzuweisungen sind im sequentiellen Fall nicht erlaubt. 
Sie können aber durch IF-ELSIF-ELSE- oder CASE-Anweisungen 
abgebildet werden. 


Die Verzögerungsmodelle sind wie bei den nebenläufigen Zuwei- 
sungen zu verwenden ("Inertial" als Defaultmodell, "Transport" durch 
explizite Kennzeichnung mit dem Schlüsselwort TRANSPORT). Das 
"Reject-Inertial"-Modell (93) ist entsprechend der ebenfalls oben 
beschriebenen Syntax anzuwenden. 


6.5.2 Variablenzuweisungen 


Die innerhalb von Prozessen und Unterprogrammen verwendeten 
Variablen (zeitabhängige Objekte ohne Aufzeichnung des Verlaufs 
über der Zeit) können nur unverzögert zugewiesen werden. Sie eignen 
sich z.B. zur Speicherung von Zwischenergebnissen. Wenn möglich, 
sollten Variablen anstelle von Signalen verwendet werden, da sie bei 
der Simulation weniger Verwaltungsaufwand (Rechenzeit, Speicher- 
platz) als Signale erfordern. 


Die Syntax für Variablenzuweisungen lautet: 
var_name := value_expr ; 


Als neuer Variablenwert (value_expr) kann entweder der Wert ei- 
nes anderen Objektes (Signal, Variable, Konstante), ein expliziter Wert 
oder ein Ausdruck angegeben werden. 


Man beachte den Unterschied zum Signalzuweisungsoperator (":=" 
anstelle von "<="). Ein weiterer Unterschied zur Signalzuweisung liegt 
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im Ausführungszeitpunkt: während Signalzuweisungen erst am Ende 
eines Delta-Zyklus nach Ausführung aller aktiven Prozesse durchge- 
führt werden, werden Variablen unmittelbar, d.h. bei Erreichen der 
entsprechenden Anweisung im sequentiellen Ablauf zugewiesen. Die 
Konsequenzen aus diesem Sachverhalt und Beispiele hierzu werden im 
Kapitel über den Simulationsablauf (Kapitel 8) aufgezeigt. 


Das folgende Beispiel illustriert die Verwendung von sequentiellen 
Signal- und Variablenzuweisungen: 


ENTITY mult IS 
PORT (a, b : IN integer : 5 : OUT integer) ; 
END mult ; 


ARCHITECTURE number_one OF mult IS 
BEGIN 
PROCESS (a,b) -- Aktivierung durch Ereignisse auf a oder b 
VARIABLE vl, v2 : integer := 0; 

BEGIN 


=3*+a+r+ 7 kb; -- sequent. Variablenzuweisung 
ve :=a*b+5*vl; -- sequent. Variablenzuweisung 
y<=vl+v2; -- sequent. Signalzuweisung 
END PROCESS ; 
D number_one ; 


6.5.3 Assertions 


Die Ausgabe von Fehlermeldungen ist ebenfalls als sequentielle An- 
weisung möglich. Hier besteht zur Syntax der nebenläufigen Form nur 
ein Unterschied in der alten VHDL-Norm: Es dürfen keine Labels 
verwendet werden. 


ASSERT condition [ REPORT "message_string"] 
[ SEVERITY severity_level]; 


Wie bei allen Anweisungen in der überarbeiteten VHDL-Norm ist hier 
auch im sequentiellen Fall ein Label erlaubt. 
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Die Verknüpfung von Meldungen mit Assertions innerhalb einer An- 
weisung hat zur Folge, daß nicht bedingte Meldungen nur mit folgen- 
dem Konstrukt ausgegeben werden können: 


Mit der überarbeiteten VHDL-Syntax (V’g3) kann nun eine Meldung 
auch ohne Assertion ausgegeben werden. Dazu ist das Schlüsselwort 
REPORT alleine (mit optionaler Fehlerklasse) ausreichend. Default- 
wert für die Klasse der Meldung ist hier note: 


[report_label :] REPORT "message_string" 
[ SEVERITY severity_level] ; 


6.5.4 WAIT-Anweisung 


WAIT-Anweisungen können die Abarbeitung von sequentiellen An- 
weisungen steuern. Sie dürfen nur in Prozessen ohne "sensitivity-list" 
und in Prozeduren, die nicht von Prozessen mit "sensitivity-list" 
aufgerufen werden, auftreten. Als Argumente einer WAIT-Anweisung 
können ein oder mehrere Signale, Bedingungen oder Zeitangaben ver- 
wendet werden. Ein "WAIT;" ohne jegliches Argument bedeutet 
"warte für immer" und beendet somit die Ausführung eines Prozesses 
oder einer Prozedur. 


wWAIT [ON signal_name_l {, signal_name_n}] 
[UNTIL condition] 
[FOR time_expression] ; 
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Die einzelnen Argumente haben folgende Bedeutung für das Zeitver- 
halten von Prozessen: 


m Eine Liste von Signalen bewirkt, daß solange gewartet wird, bis 
sich mindestens eines der Signale ändert, d.h. ein Ereignis auf- 
tritt. Ein Prozeß mit einer Liste von Signalen als Argument einer 
am Ende stehenden WAIT-Anweisung entspricht somit einem 
Prozeß mit den gleichen Signalen als Elemente der "sensitivity- 
list" im Prozeßkopf. 


Ist ein Signal der Liste ein Vektor oder ein höherdimensionales 
Feld, so erfüllt bereits die Änderung eines einzigen Elementes 
die WAIT-Bedingung. 

m Eine Bedingung (condition) unterbricht die Prozeßabarbei- 
tung solange, bis die Bedingung erfüllt ist. 


Bei Angabe von Bedingung und Signalliste muß die Bedingung 
erfüllt sein und der Signalwechsel auftreten. 


7 Die Angabe eines Ausdruckes, der als Ergebnis eine Zeitangabe 
liefert (time_expression), stoppt die Prozeßabarbeitung 
maximal für diese Zeitdauer. 


Folgende Beispiele geben weitere Architekturen für das bereits er- 
wähnte Latch wieder: 


ARCHITECTURE sequential_2 OF latch IS 
BEGIN 
q_assignment: PROCESS 
BEGIN 

IF clk = '1' THEN 


q<=d; 
END IF ; 

wWAIT ON d, clk ; -- entspricht "sensitivity-list" 
END PROCESS q_assignment ; 
END sequential_2 ; 
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ARCHITECTURE sequential_3 OF latch IS 
BEGIN 


q_assignment: PROCESS 
BEGIN 


q=d; 
wAIT ON d, clk UNTIL clk 4 -- ersetzt IF-Anw. 
END PROCESS q_assignment ; 

END sequential_3 ; 


8.55 IF-ELSIF-ELSE-Anweisung 


Bedingte Verzweigungen in sequentiellen Anweisungsteilen können 
mit der IF-ELSIF-ELSE-Anweisung folgendermaßen realisiert wer- 
den: 


IF condition_1 THEN 


- sequentielle Anweisungen 


{ ELSIF condition_n THEN 


- sequentielle Anweisungen 


[ ELSE 


sequentielle Anweisungen 

ef] 
END IF ; 
Zwingend erforderlich sind nur die erste Bedingung und die Kenn- 
zeichnung des Endes der Struktur durch "END IF;". Die ELSIF- 


und ELSE-Teile sind optional, wobei ersterer mehrfach auftreten 
kann. 
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Mit der überarbeiteten Syntax (Y'g93) kann einer IF-ELSIF-ELSE- 
Anweisung auch ein Label gegeben werden. Entsprechend kann in der 
END IF-Anweisung dieses Label wiederholt werden: 


[if_label :] IF condition_l1 THEN 


END IF [if_label] ; 


6.5.6 CASE-Anweisung 


Eine weitere Möglichkeit der bedingten Ausführung bestimmter An- 
weisungen liegt in der CASE-Anweisung. Sie bietet sich insbesondere 
bei mehrfacher Verzweigung basierend auf einem Ausdruck an: 


CASE expression IS 
{ WHEN value_n => 


-- sequentielle Anweisungen 


Sans ve 
[ WHEN OTHERS => 


-- sequentielle Anweisungen 


END CASE ; 


Im Gegensatz zu IF-ELSIF-ELSE müssen hier allerdings alle Werte 
(value_n), die der Ausdruck (expression) annehmen kann, ex- 
plizit angegeben werden. Um die noch nicht behandelten Werte abzu- 
fragen, kann auch das Schlüsselwort OTHERS dienen. 


Folgende Beispiele einer bedingten Verzweigung sind Äquivalent: 


ENTITY four_byte_rom IS 
PORT (address : IN integer RANGE 1 TO 4; 


contents : OUT bit_vector (1 TO 8) ) ; 
END four_byte_rom; 
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ECTURE if_variante OF four_byte_rom IS 


ESS (address) 


IF address = 1 THEN 

cöntents <= ("0,1000 TINTEN GEIL) 5 
‚SIF address = 2 THEN 

contents <= "00111111" ; 

‚SIF address = 3 THEN 

contents <= b"11111100" ; 

‚SE 
contents <= x"f0" ; 
END IF ; 

D PROCESS ; 
if_variante ; 


ECTURE case_variante_l OF four_byte_rom IS 


ESS (address) 


CASE address IS 
WHEN 1 => contents <= 

(207,270, 01 TONER FE ZELIZELNI EG 
WHEN 2 => contents <= "00111111" 
WHEN 3 => contents <= b"11111100" ; 
WHEN OTHERS => contents <= x"f£fO" 

END CASE ; 

END PROCESS ; 

D case_variante_1 ; 


Beide Varianten verwenden dabei zur weiteren Reduzierung des Code- 
Umfangs die Möglichkeit, Bit-Vektoren als Strings anzugeben. An- 
stelle der letzten Alternative ("WHEN OTHERS") hätte hier auch 
"WHEN 4" stehen können. 


Mit Hilfe von Oder-Verknüpfungen ("|") oder Bereichsangaben (TO, 
DOWNTO) können mehrere Fälle des Ausdruckes für gleiche Anwei- 
sungsteile zusammengefaßt werden. Damit ergibt sich eine weitere Ar- 
chitekturalternative: 
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ECTURE case_variante_2 OF four_byte_rom 


ESS (address) 


E address IS 

HEN 1 | 2 => conten "00" ; 
conten WELT 

EN OTHERS => conten LT 
conten "90" 5 


CASE ; 

E address IS 

HEN 2 TO 4 => conten "ELT 5 
HEN OTHERS => conten "00" 5 
CASE ; 
address IS 
EN 1 TO 3 => conten au De 
EN OTHERS => conten "oor 
CASE ; 

END PROCESS ; 

D case_variante_2 ; 


Die einheitliche Handhabung von Labels und Rahmensyntax in der 
überarbeiteten VHDL-Norm (93) erlaubt auch für die CASE-An- 
weisung folgende Syntaxvariante: 


[case_label :] CASE expression IS 


END CASE [case_label] ; 


6.5.7 NULL-Anweisung 


Die NULL-Anweisung: 


NULL ; 


führt keine Aktion aus. Sie dient zur expliziten Kennzeichnung von 
aktionslosen Fällen in IF- und vor allem in CASE-Anweisungen. 


Die Modellierung des Latches mit Hilfe einer CASE-Anweisung Könn- 
te somit folgendes Aussehen haben: 
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ARCHITECTURE sequential_4 OF latch IS 
BEGIN 
q_assignment: PROCESS (clk, d) 
BEGIN 

CASE clk IS 


WHEN '1' > q<=d; 
WHEN OTHERS => NULL ; 
END CASE ; 
END PROCESS q_assignment ; 
END sequential_4 ; 


6.5.8 LOOP-Anweisung 


Iterationsschleifen, d.h. mehrfach zu durchlaufende Anweisungsblök- 
ke, können mittels der LOOP-Anweisung realisiert werden. Dabei exi- 
stieren die folgenden drei Alternativen: FOR-Schleife, WEILE-Schleife 
und Endlosschleife: 


[loop_label :] FOR range LOOP 


segquentielle Anweisungen 
END LOOP [loop_label] ; 


[loop_label :] WHILE condition LOOP 


sequentielle Anweisungen 


END LOOP [loop_label] ; 


[loop_label :] LOOP 
-- sequentielle Anweisungen 


END LOOP [loop_label] ; 
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Die Schleifensteuerstrukturen range und condition werden wie 
bei der GENERATE-Anweisung verwendet. Für die Angabe von Berei- 
chen (range) wird implizit eine Laufvariable deklariert. 


6.5.9 EXIT- und NEXT-Anweisung 


EXIT- und NEXT-Anweisungen dienen zum vorzeitigen Ausstieg aus 
Schleifenanweisungen bzw. zum vorzeitigen Abbruch des aktuellen 
Durchlaufs. Mit NEXT wird direkt zum Beginn des nächsten Schlei- 
fendurchlaufes gesprungen, mit EXIT wird die Schleife ganz verlas- 
sen. Da Schleifen, wie IF- und CASE-Anweisungen, auch verschach- 
telt aufgebaut sein können, kann mit EXIT und NEXT auch aus hie- 
rarchisch höher liegenden Schleifen ausgestiegen werden. Dazu muß 
das Label der entsprechenden Schleife angegeben werden: 


NEXT [loop_label] [WHEN condition] ; 


EXIT [loop_label] [WHEN condition] ; 


Im folgenden werden zwei Beispiele für Modelle mit Schleifen ge- 
zeigt. Das Modell array_compare vergleicht zwei 9x9-Matrizen 
miteinander. Der Ausgang equal wird true, falls alle Elemente der 
Matrizen übereinstimmen. 


PACKAGE array_pack IS 
TYPE bit_matrix IS ARRAY 
(integer RANGE <>, integer RANG 
END array_pack ; 


ENTITY array_compare IS 
PORT (a, b : IN 
work.array_pack.bit_matrix (8 DOWNTO 0, 8 DOWNTO 0) ; 
equal : OUT boolean) ; 
END array_compare ; 
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ARCHITECTURE behavioral OF array_compare IS 
BEGIN 
cmp : PROCESS (a,b) 
VARIABLE equ : boolean ; 
BEGIN 
equ := true ; 
first_dim_loop : FOR k IN a'RANGE (1 


LOOP 


) 
second_dim_loop : FOR 1 IN a'RANGE (2) LOOP 
IF a(k,1l) /= b(k,1l) THEN -- Elementvergleich 


equ := false ; 

-- Ausstieg aus aeusserer Schleife beim ersten, 
-- nicht identischen Matrixelement 
EXIT first_dim_loop ; 

END IF ; 
END LOOP ; 
END LOOP ; 
equal <= equ ; 
END PROCESS ; 
D behavioral ; 


Das folgende Modell (n_time_left_shift) rotiert den Ein- 
gangsvektor in_table um .n Stellen nach links und gibt den neuen 
Vektor über den Port out_table aus. 


ENTITY n_time_left_shift IS 
GENERIC (n : natural := 2) ; 


PORT (in_table : IN bit_vector (0 TO 31); 
out_table : OUT bit_vector (0 TO 31)) ; 
END n_time_left_shift ; 
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ARCHITECTURE behavioral OF n_time_left_shift IS 


B 


EGIN 


PROCESS (in_table) 

VARIABLE count : natural ; 

VARIABLE table : bit_vector (0 TO 32) ; 

EGIN 
count := 0 ; 

table (0 TO 31) := in_table ; 
n_time_loop : WHILE count < n LOOP 

count := count +1; 

table (table'HIGH) := table (table'LOoW) ; 

left_shift_loop : 

FOR j IN table'LOW TO table'HIGH - 1 LOOP 
table (j) := table(j+t1) ; 

END LOOP left_shift_loop; 

END LOOP n_time_loop ; 

out_table <= table (0 TO 31) ; 

END PROCESS ; 

D behavioral ; 


Unterprogramme 


Ähnlich wie in höheren Programmiersprachen können in VHDL 
Unterprogramme in Form von Funktionen oder Prozeduren realisiert 
werden. 


m) 


Funktionen werden mit keinem, einem oder mehreren Argu- 
menten aufgerufen und liefern einen Ergebniswert zurück. Der 
Funktionsaufruf kann an den gleichen Stellen in Ausdrücken 
und Anweisungen stehen, an denen der Typ des Ergebniswertes 
erlaubt ist. Funktionen werden explizit durch das Schlüsselwort 
RETURN unter Angabe des Rückgabewertes verlassen. 


Prozeduren werden mit einer Liste von Argumenten aufgerufen, 
die sowohl Eingaben als auch Ausgaben oder bidirektional sein 
können. Der Aufruf einer Prozedur ist ein eigenständiger Befehl 
(sequentiell oder nebenläufig). Prozeduren werden bis zu einer 
RETURN-Anweisung oder bis zum Ende (entsprechend einem 
Prozeß mit "sensitivity-list") abgearbeitet. 
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Funktionen und Prozeduren unterscheiden sich damit in folgenden 
Punkten: 


Funktionen Prozeduren 
Argumentmodi IN IN, OUT, INOUT 
Argumentklassen Konstanten, Konstanten, 

Signale Signale, Variablen 
Rückgabewerte exakt einer beliebig viele (auch O) 
Aufruf in typkonformen als eigenständige, se- 

Ausdrücken und quentielle oder neben- 

Anweisungen läufige Anweisung 
RETURN-Anweisung obligatorisch optional 


Die Beschreibung der Funktionalität eines Unterprogramms Kann (zu- 
sammen mit der Vereinbarung der Schnittstellen) in den Deklarations- 
teilen von Entity, Architektur, Block, Prozeß oder im Package Body 
stehen. Außerdem können Funktionen und Prozeduren selbst wieder 
in den Deklarationsteilen von anderen Funktionen und Prozeduren 
spezifiziert werden. 


Weiterhin besteht die Möglichkeit, die Funktionalität (Unterpro- 
grammdefinition) und die Schnittstellenbeschreibung (Unterpro- 
grammdeklaration) zu trennen. Die Schnittstellenbeschreibung allein 
kann dann auch in Packages auftreten. 


Eine solche Aufteilung bietet sich unter Ausnutzung der Abhängig- 
keiten beim Compilieren von Package und Package Body an: Die 
Schnittstellenbeschreibung wird im Package plaziert, während die 
Funktionalität erst im Package Body festgelegt wird. Eine nachträgli- 
che Änderung der Funktionalität bedingt dann nur das Neucompi- 
lieren des Package Body. Die Design-Einheiten, die das Unterpro- 
gramm verwenden, müssen nicht neu übersetzt werden. 
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6.6.1 Funktionen 


Wie bereits erwähnt, dienen Funktionen zur Berechnung eines Wertes 
und können in Ausdrücken und anderen Anweisungen direkt einge- 
setzt werden. 


Für eine flexiblere Beschreibung (s.o.) bietet sich eine Aufteilung in 
Funktionsdeklaration (Schnittstellenbeschreibung) und -definition 
(Funktionalität) an. 


6.6.1.1 Funktionsdeklaration 


Die Funktionsdeklaration enthält eine Beschreibung der Funktions- 
argumente und des Funktionsergebnisses: 


FUNCTION function_name 
[ (€ t lfarg_class_m] arg_name_m {„arg_name_n} 
[IN] arg_type_m [:= def_value_m] ;} 
[arg_class_o] arg_name_o {„arg_name_p} 
[IN] arg_type_o [:= def_value_o] ) ] 

RETURN result_type ; 


Erlaubt sind also auch Funktionen ohne jegliches Argument. 


Der Funktionsname (function_name) kann auch ein bereits defi- 
nierter Funktionsname oder Operator sein. In diesem Fall spricht man 
von "Überladung" der Funktion. Diese Möglichkeit wird in Kapitel 11 
ausführlich diskutiert. 


Als Argumentklasse (arg_class) sind Signale und Konstanten er- 
laubt. Deren Angabe durch die Schlüsselwörter SIGNAL oder 
CONSTANT ist optional. Der Defaultwert ist CONSTANT. 


Als Argumenttypen (arg_type) können in der Schnittstellenbe- 
schreibung von Unterprogrammen neben eingeschränkten auch un- 
eingeschränkte Typen verwendet werden. 


FUNCTION demo (SIGNAL datal, data2 : IN integer; 


CONSTANT cl : real) RETURN boolean; 
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6.6.1.2  Funktionsdefinition 


Hier muß die Schnittstellenbeschreibung wiederholt werden. Das nach- 
folgende Schlüsselwort IS kennzeichnet den Beginn der Funktionsbe- 
schreibung: 


FUNCTION function_name 
[ (€ t lfarg_class_m] arg_name_m {„arg_name_n} 


[IN] arg_type_m [:= def_value_m] ;} 
[arg_class_o] arg_name_o {,„arg_name_p} 
[IN] arg_type_o [:= def_value_o] ) ] 


RETURN result_type IS 
-- Deklarationsanweisungen 
BEGIN 
-- sequentielle Anweisungen 


-- RETURN-Anweisung obligatorisch 
-- keine WAIT-Anweisung in Funktionen! 


END [function_name] ; 


Im Deklarationsteil von Funktionen können lokale Typen und Unter- 
typen, Konstanten, Variablen, Files, Aliase, Attribute und Gruppen 
(93) deklariert werden. USE-Anweisungen und Attributdefinitionen 
sind dort ebenfalls erlaubt. Außerdem können im Deklarationsteil 
andere Prozeduren und Funktionen deklariert und definiert werden. 


Die eigentliche Funktionsbeschreibung besteht aus sequentiellen An- 
weisungen (ausgenommen WAIT-Anweisung) und kann selbst wieder 
Unterprogrammaufrufe enthalten. Sämtliche Argumente können in- 
nerhalb der Funktion nur gelesen werden (Modus IN) und dürfen 
deshalb nicht verändert werden. Die Funktion muß an mindestens ei- 
ner Stelle mit der RETURN-Anweisung verlassen werden: 


RETURN result_value ; 


Das Ergebnis der Funktion (Rückgabewert result_value) kann in 
Form von expliziten Wertangaben, mit Objektnamen oder durch Aus- 
drücke angegeben werden. 
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Die Vereinheitlichung der Rahmensyntax in Yg3 führt zu folgender 
Syntaxalternative: 


FUNCTION function_name ... IS 
BEGIN 


END [FUNCTION] [function_name] ; 


Einige Beispiele für die Definition von Funktionen: 


-- Umwandlung von bit in integer ('0' -> 0, '1' -> 1) 
FUNCTION bit_to_integer (bit_a : bit) RETURN integer IS 
BEGIN 
IF bit_a = '1' THEN RETURN 1 ; 
ELSE RETURN 0 ; 

END IF ; 


END bit_to_integer ; 


-- Zaehlen der Einsstellen in einem Bitvektor unbestimmter 
Laenge (flexibles Modell). Abfrage der aktuellen Vektor 

-- laenge durch das Attribut RANGE. 

FUNCTION count_ones (a : bit_vector) RETURN integer IS 

VARIABLE count : integer := 0 ; 

BEGIN 
FOR c IN a'RANGE LOOP 

IF a(c) = '1' THEN count := count +1; 

END IF ; 

END LOOP ; 

RETURN count ; 

count_ones ; 
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-- Exklusiv-NOR-Verknuepfung fuer allgemeine Bitvektoren 
FUNCTION exnor (a, b : bit_vector) RETURN bit_vector IS 
-- Normierung auf gleiche Indizierung der beiden Argumente 


-- ueber Aliase c und d: 

ALIAS c : bit_vector (1 TO a'LENGTH) IS a; 
ALIAS d : bit_vector (1 TO b'LENGTH) ISb; 
VARIABLE result : bit_vector (1 TO a'LENGTH) ; 
EGIN 


ERT a'LENGTH = b'LENGTH 
REPORT "Different Length of vectors!" ; 
FOR k in c'RANGE LOOP 
IF (c(k) = '1' AND d(k) '0') OR 
(c(k) = '0' AND d(k) = '1') THEN result (k) := '0' 
ELSE result (k) := '1' ; 
END IF ; 
END LOOP ; 
RETURN result ; 
END exnor ; 


6.6.1.3  Funktionsaufruf 


Der Aufruf einer Funktion geschieht unter Angabe der aktuellen Ar- 
gumentwerte in Form von expliziten Wertangaben, Objektnamen oder 
Ausdrücken. Der Aufruf muß an einer Stelle stehen, an der auch der 
Ergebnistyp der Funktion erlaubt ist. Für die Übergabe der Argu- 
mentwerte ist, wie bei der Port Map, die Zuordnung der Werte über 
ihre Position ("positional association") möglich: 


function_name [(arg_l_value {, arg_n_value})] 


oder kann durch die explizite Zuordnung zwischen den Funktions- 
argumenten (arg_name) und den Aufrufwerten ("named associ- 
ation") erfolgen: 


function_name [( arg_name_l => arg_l_value 
{, arg_name_n => arg_n_value})] 


Die Kombination der beiden Aufrufmethoden ist unter Beachtung der 
gleichen Regeln wie bei der Port Map erlaubt. Wird ein Aufrufwert 
nicht angegeben, dann gilt der in der Funktionsdeklaration festgelegte 
Defaultwert (def_value). 
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Die oben definierten Funktionen lassen sich beispielsweise innerhalb 
von Signalzuweisungen aufrufen: 


ENTITY functions IS 

PORT (inl, in2 : IN bit_vector (8 DOWNTO 1) :="11111111"; 
exnor_out : OUT bit_vector (8 DOWNTO 1) ); 

END functions; 


ARCHITECTURE behavioral OF functions IS 
SIGNAL x2 : bit_vector (2 DOWNTO 1); 


( 

SIGNAL i,j : integer := 0; 
EGIN 

exnor_out <= exnor (inl, in2); 

x2 <= exnor (a => inl(2 DOWNTO 1), b => in2(2 DOWNTO 1)); 
i <= bit_to_integer (bit_a => inl1(8)) + count_ones (in2); 

jJ <= count_ones ("11101001011100101001001"); 
END behavioral; 


6.6.1.4  "Impure Functions" 93 


Funktionen sollten nach der ursprünglichen Definition der Sprache 
VHDL keinerlei "Seiteneffekte" aufweisen, d.h. der Aufruf einer Funk- 
tion zu verschiedenen Zeitpunkten und an verschiedenen Stellen in 
VHDL-Modellen soll für gleiche Argumente auch gleiche Ergebnisse 
liefern. Auf Objekte, die nicht als Argumente oder in der Funktion 
selbst deklariert wurden, kann daher auch nicht zugegriffen werden. 


Viele Hardwareentwickler empfanden diese im Englischen als "pure" 
bezeichneten Funktionen als eine große Einschränkung. Ihre Forde- 
rung nach Lockerung der Richtlinien für Funktionen wurde in Y 93 
durch die Einführung von sog. "impure functions" berücksichtigt. 


Herkömmliche, "pure" Funktionen werden wie bisher gehandhabt. Sie 
können nun aber optional mit dem Schlüsselwort PURE gekennzeich- 
net werden: 


[PURE] FUNCTION function_name ... IS 
BEGIN 
END [FUNCTION] [function_name] ; 
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Die neue Klasse der "impure functions", gekennzeichnet durch das 
Wort IMPURE, kann nun auf globale Objekte wie z.B. Files zugreifen. 
Die Argumente müssen aber auch weiterhin den Modus IN besitzen. 
"Impure functions" werden wie folgt beschrieben (93): 


IMPURE FUNCTION function_name ... IS 
BEGIN 
END [FUNCTION] [£function_name] ; 


Typische Anwendungsfälle für solche Funktionen sind z.B. die Erzeu- 
gung von Zufallszahlen oder das Lesen von Files. 


6.6.2 Prozeduren 


Prozeduren unterscheiden sich von Funktionen hauptsächlich durch 
ihren Aufruf und die Art der Argumente. Zusätzlich zum Modus IN 
sind auch OUT und der bidirektionale Modus INOUT erlaubt. Weiter- 
hin sind neben Konstanten und Signalen auch Variablen als Argu- 
mentklasse gestattet. 


6.6.2.1 Prozedurdeklaration 


Die Prozedurdeklaration enthält die Beschreibung der an die Prozedur 
übergebenen Argumente (Modus IN und INOUT) und die von der 
Prozedur zurückgelieferten Ergebnisse (Modus INOUT und OUT): 


PROCEDURE procedure_name 
[({ l[arg_class_m] arg_name_m {,arg_name_n} 


[arg_modus_m] arg_type_m [:= def_value];} 
[arg_class_o] arg_name_o {„arg_name_p} 
arg_modus_o arg_type_o [:= def_value])]; 


Der Defaultwert des Argumentmodus (arg_modus) ist IN. 


Die Argumentklasse (arg_class) kann neben SIGNAL und CON- 
STANT auch VARIABLE sein. Defaultwert der Klasse ist für den 
Modus IN CONSTANT, für die Modi OUT und INOUT VARIABLE. 
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E hello; 
EB d_ff ( CONSTANT delay : IN time :=2 ns; 


SIGNAL d, clk : IN bit ; 
SIGNAL q, q_bar : OUT bit ); 


6.6.2.2 Prozedurdefinition 


Entsprechend der Funktionsdefinition muß die Schnittstellenbeschrei- 
bung mit dem Schlüsselwort IS wiederholt werden: 


PROCEDURE procedure_name 
[({ l[arg_class_m] arg_name_m {,arg_name_n} 


[arg_modus_m] arg_type_m [:= def_value];} 
[arg_class_o] arg_name_o {„arg_name_p} 

arg_modus_o arg_type_o [:= def_value])] 
IS 


-- Deklarationsanweisungen 


-- sequentielle Anweisungen 
-- optional: RETURN-Anweisung 


END [procedure_name] ; 


Die Prozedurbeschreibung kann aus allen möglichen sequentiellen 
Anweisungen, einschließlich der WAIT-Anweisung, bestehen. Argu- 
mente vom Typ IN können innerhalb von Prozeduren nur gelesen 
werden; verändert werden dürfen nur Argumente des Typs OUT und 
INOUT. Prozeduren können explizit mit dem Schlüsselwort RETURN 
(ohne Argument) verlassen werden oder werden bis zum Ende abge- 
arbeitet. 


Die Vereinheitlichung der Rahmensyntax in Y’g3 führt bei optionaler 
Wiederholung des Schlüsselwortes PROCEDURE zu folgender Alter- 
native für den Prozedurrahmen: 
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PROCEDURE procedure_name ... IS 
BEGIN 
END [PROCEDURE] [procedure_name] ; 


Zwei Beispiele für Prozeduren: 


-- Prozedur ohne Argumente 
PROCEDURE hello IS 

BEGIN 
ASSERT false REPORT "Hello world!" SEVERITY note ; 
END hello ; 


Beschreibung eines D-Flip-Flops innerhalb einer Prozedur 
ROCEDURE d_ff (CONSTANT delay : IN time :=2 ns; 
SIGNAL d, clk : IN bit ; 

SIGNAL q, q_bar: OUT bit ) IS 


EGIN 
IF clk = '1' AND clk'EVENT THEN 
q <=d AFTER delay ; 
q_bar <= NOT d AFTER delay ; 

END IF ; 

END d_ff ; 


6.6.2.3  Prozeduraufruf 


Der Aufruf einer Prozedur erfolgt unter Angabe der Argumentwerte 
als eigenständige, sequentielle oder nebenläufige Anweisung. Wie 
beim Funktionsaufruf ist eine Angabe der Aufrufwerte durch Position 
("positional association"): 


procedure_name [(arg_l_value{, arg_n_value})]; 
oder eine explizite Zuordnung ("named association") möglich: 


procedure_name [( arg_name_l => arg_l_value 
{, arg_name_n => arg_n_value})]; 


Die Kombination der beiden Aufrufmethoden ist unter Beachtung der 
gleichen Regeln wie bei der Port Map erlaubt. Wird ein Aufrufwert 
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nicht angegeben, dann gilt der in der Prozedurdeklaration festgelegte 
Defaultwert (def_value). 


Im nebenläufigen Fall des Prozeduraufrufes ist ein Label erlaubt: 


[proc_call_label :] procedure_name [...] ; 


Erläutert werden soll dies anhand einer alternativen Darstellung eines 
4-bit-Registers, welches obige D-Flip-Flop-Prozedur verwendet: 


ENTITY four_bit_register IS 
PORT (cl1k «IN. Die; 
in_d : IN bit_vector (3 DOWN] 


out_g, out_q_bar : OUT bit_vector (3 DOWNT 
END four_bit_register ; 


ARCHITECTURE with_procedures OF four_bit_register IS 
USE work.my_pack.all ; -- enthaelt Prozedur d_ff 
BEGIN 
-- Varianten eines nebenlaeufigen Prozeduraufrufes 
a_ff_3 : d_f£f (1.5 ns, in_d(3), clIk, 
out_q(3), out_q_bar(3)) ; 
a_ff_2 : d_ff (delay => 1.7 ns, d => in_d(2), clk => clIk, 
q => out_q(2), q_bar => out_q_bar(2)) ; 
a_ff1 : d_ff (1.9 ns, in_d(1), cik, 
q_bar => out_q_bar (1), q => out_q(1)) ; 
a_ff_O : d_ff (q_bar => out_q_bar(0), clk => clk, 
q => out_q(0), d => in_d(0)) ; 
Defaultwert fuer delay: 2 ns 
END with_procedures; 


Bei einem nebenläufigen Prozeduraufruf wird die Prozedur immer 
dann aktiviert, wenn sich mindestens ein Argumentwert (Modus IN 
oder INOUT) ändert. Der Aufruf Kann also auch als Prozeß interpre- 
tiert werden, welcher die genannten Argumente in seiner "sensitivity- 
list" enthält. 


Diese einfache Möglichkeit, prozeßähnliche Konstrukte mehrfach in 
ein VHDL-Modell einzufügen, wird durch folgendes Beispiel verdeut- 
licht. Es handelt sich um zwei äquivalente Teile eines Modells, die ein 
Signal überwachen: 
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ENTITY anything_one IS 

PORT (sig_a, sig_b : IN bit; sig_c : OUT bit ) ; 
P DURE monitoring (SIGNAL a * IN bit; 
CONSTANT sig_name : IN string) 


B 


ERT false REPORT "Event on signal " & sig_name 
EVERITY note ; 

END monitoring ; 

BEGIN 


mon_sig_a : monitoring (sig_a, "anything_one:sig_a") 


END anything_one ; 


ARCHITECTURE behavioral OF anything_one IS 
BEGIN 
mon_sig_b : monitoring (a => sig_b, 
sig_name => "anything_one:sig_b") 
sig_c <= sig_a AND NOT sig_b ; 
END behavioral ; 


Diese erste Variante verwendet nebenläufige Prozeduraufrufe, die 
nicht nur in der Architektur, sondern auch im Anweisungsteil der Enti- 
ty auftreten können (sofern es sich um sog. passive Prozeduren han- 
delt). 


Die nachfolgenden Varianten beschreiben das gleiche Verhalten mit 
Hilfe von ASSERT-Anweisungen und passiven Prozessen. Auch diese 
dürfen im Anweisungsteil einer Entity stehen: 


ENTITY anything_two IS 
PORT (sig_a, sig_b : IN bit; sig_c : OUT bit ) ; 
BEGIN 
mon_sig_a : PROCESS (sig_a) 
EGIN 


ERT false REPORT "Event on signal anything_two:sig_a" 
ERITY note ; 

ROCHESS ; 

thing_two ; 
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ECTURE behavioral OF anything_two IS 


sig_b : PROCESS (sig_b) 


ERT false REPORT "Event on signal anything_two:sig_b" 
FVERITY note ; 
ROCHESS ; 
sig_c <= sig_a AND NOT sig_b ; 
D behavioral ; 


ENTITY anything_three IS 


PORT (sig_a, sig_b : IN bit; sig_c : OUT bit ) ; 

BEGIN 
mon_sig_a : ASSERT (sig_a'EV = false) 

REPORT "Event on signal anything_three:sig_a" 

SEVERITY note ; 

END anything_three ; 


ARCHITECTURE behavioral OF anything_three IS 
BEGIN 
mon_sig_b : ASSERT (sig_b'EVENT = false) 
REPORT "Event on signal anything_three:sig_b" 
SEVERITY note ; 
sig_c <= sig_a AND NOT siq_b ; 
END behavioral ; 
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Die Sprache VHDL bietet bei der strukturalen Beschreibung elektroni- 
scher Systeme ein hohes Maß an Flexibilität. So können unter an- 
derem Modelle dadurch umkonfiguriert werden, daß man ihre interne 
Funktion austauscht, ihre Verdrahtung ändert oder die Modellparame- 
ter modifiziert. 


"Konfigurieren" von VHDL-Modellen bedeutet im einzelnen also: 


I die Auswahl der gewünschten Architekturalternative für eine En- 
tity (d.h. Auswahl der internen Modellfunktion), 


A die Auswahl der zu verwendenden Modelle für die einzelnen In- 
stanzen bei strukturalen Modellen, 


I das Verbinden von Signalen und Ports auf den unterschiedli- 
chen Hierarchieebenen, 


A die Zuweisung von Werten an die Parameter (Generics) der ein- 
zelnen Instanzen. 


Diese Konfigurationsangaben werden in einer eigenen Design-Einheit, 
der "Configuration", zusammengefaßt. Änderungen an dieser Design- 
Einheit erfordern kein erneutes Compilieren des Gesamtmodells, so 
daß verschiedene Modellvarianten schnell untersucht werden können. 


Daneben können auch in Deklarationsteilen von Architekturen und 
Blöcken und in den GENERIC MAP- und PORT MAP-Anweisungen 
der Komponenteninstantiierung Konfigurationsanweisungen stehen. 


In vielen Fällen werden bei fehlenden Konfigurationskonstrukten 
Defaultwerte verwendet. 
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7.1 Konfiguration von Verhaltensmodellen 


Bei Verhaltensmodellen ist nur eine Information erforderlich: Die 
Auswahl der gewünschten Architekturalternative für eine Schnittstel- 
lenbeschreibung. Dies wird in der Design-Einheit "Configuration" 
durch eine einfache Blockkonfigurationsanweisung vorgenommen: 


CONFIGURATION conf_name OF entity_name IS 


generelle USE-Anweisungen 
-- Attributzuweisungen 


FOR arch_name -- Architekturauswahl 
END FOR ; 
END [CONFIGURATION] [conf_name] ; 


Die optionale Wiederholung des Schlüsselwortes CONFIGURATION 
in der END-Anweisung ist nur in der neuen VHDL-Norm (93) ge- 
stattet. 


7.2 Konfiguration von strukturalen Modellen 


Bei strukturalen Modellen muß neben der Architekturauswahl jede in- 
stantiierte Komponente (jeder instantiierte Sockeltyp) konfiguriert 
werden, d.h. es muß festgelegt werden, in welcher Form ein existieren- 
des VHDL-Modell in diese Sockelinstanzen eingesetzt wird. Dazu soll 
zunächst ein Blick auf die unterschiedlichen Ebenen bei strukturalen 
Modellen und deren Schnittstellen geworfen werden. 


Das Konzept der strukturalen Modellierung über die Ebenen: Kompo- 
nentendeklaration (Sockeltyp), Komponenteninstantiierung (Verwen- 
dung des Sockeltyps, "Sockelinstanz") und Komponentenkonfigura- 
tion (Einsetzen des Modells, "IC") weist folgende Schnittstellen auf: 


m Schnittstelle zwischen dem eingesetzten Modell und der Kom- 
ponente. Die Generics und Ports des ersteren werden dabei als 
"formal", die der letzteren als "local" bezeichnet. Hierfür benutzt 
man GENERIC MAP- und PORT MAP-Anweisungen in der De- 
sign-Einheit "Configuration". 
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m Schnittstelle zwischen der Komponenteninstanz und der Kom- 
ponente. Die Signale, mit denen die Instanzen verdrahtet wer- 
den, und die Parameter, die an die Instanzen übergeben werden 
unter dem Begriff "actual" zusammengefaßt. Die Zuordnungen 
werden durch entsprechende GENERIC MAP- und PORT MAP- 
Anweisungen bei der Komponenteninstantiierung definiert. 


In der "Configuration" wird mit hierarchisch geschachtelten FOR- 
USE-Anweisungen festgelegt, welche Modelle für die instantiierten 
Komponenten (Sockel) verwendet werden, wie die Ports verknüpft und 
welche Parameterwerte übergeben werden. 


Man unterscheidet dabei zwischen Blockkonfigurationsanweisungen 
(für Architektur, BLOCK, GENERATE) und Komponentenkonfigura- 
tionsanweisungen (für die einzelnen Instanzen). 


7.2.1 Konfiguration von Blöcken 


Blöcke repräsentieren eine Hierarchieebene, die selbst wieder Kompo- 
nenten und Blöcke enthalten kann. Dementsprechend können in einer 
Blockkonfiguration Komponentenkonfigurationen und auch weitere 
Blockkonfigurationen enthalten sein. 


Auf oberster Ebene eines strukturalen Modells wird zunächst die ge- 
wünschte Architektur ausgewählt: 


CONFIGURATION conf_name OF entity_name IS 


= generelle USE-Anweisungen 
-- Attributzuweisungen 


FOR arch_name -- Architekturauswahl 
-- weitere Blockkonfigurationen 
ELBE: -- Komponentenkonfigurationen 
END FOR ; 
END [CONFIGURATION] [conf_name] ; 


Die Wiederholung des Schlüsselwortes CONFIGURATION am Ende 
der Design-Einheit ist nur in der neuen VHDL-Norm (093) gestattet. 
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Weitere Blockkonfigurationsanweisungen dienen zur näheren Be- 
schreibung von GENERATE- und BLOCK-Anweisungen: 


FOR block_name 

-- weitere Blockkonfigurationen 
Sr -- Komponentenkonfigurationen 
END FOR ; 


FOR gen_name [(index_range)] 
-- weitere Blockkonfigurationen 
a -- Komponentenkonfigurationen 
END FOR ; 
7.2.2 Konfiguration von Komponenten 


Die Konfigurationsanweisungen für Komponenten stellen den Zusam- 
menhang zwischen dem in der Architektur instantiierten Komponen- 
tensockel und dem darin einzusetzenden Modell her. Bei diesem Mo- 
dell handelt es sich um ein bereits compiliertes Modell, das in der Bib- 
liothek work oder in einer anderen Resource-Library abgelegt ist. 
Diese Modelle müssen also vor dem Übersetzen der Konfiguration an- 
gelegt und compiliert werden. Mit den von der Komponentenin- 
stantiierung bekannten GENERIC MAP- und PORT MAP-Anweisun- 
gen werden die "local" und "formal" Ports und Generics verbunden. 


Das jeweils einzusetzende Modell kann folgendermaßen beschrieben 
werden: 


m durch Angabe seiner Konfiguration (conf_name): 


FOR inst_name_l {„inst_name_n} : comp_name 
USE CONFIGURATION conf_name 
[ GENERIC MAP (...) ] 
[ PORT MAP (es) 1% 
END FOR ; 


m oder durch den Namen seiner Schnittstellenbeschreibung 
(entity_name) mit gewünschter Architektur (arch_name): 
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FOR inst_name_l {„inst_name_n} : comp_name 


USE ENTITY entity_name [(arch_name) ] 
[ GENERIC MAP (...) ] 
[ PORT MAP (es) rar 


END FOR ; 


m) 


Möchte man einen Sockel (Komponenteninstanz) unbestückt 
lassen, genügt das Schlüsselwort OPEN. 


FOR inst_name_l {„inst_name_n} : comp_name 


USE OPEN ; 


END FOR ; 


Folgende Regeln werden angewandt, falls ein oder mehrere Teile die- 
ser Angaben (arch_name, GENERIC MAP, PORT MAP) in der Kon- 
figuration fehlen: 


I 


180 


Bei fehlender Architekturangabe (arch_name) wird ein Mo- 
dell ohne Funktion bzw. nur mit den passiven Anweisungen der 
Entity eingesetzt. 


Stimmen Namen, Modi und Typen der Signale auf local- und 
formal-Ebene überein, so werden sie nach Namen miteinander 
verbunden (Default-PORT MAP). 


Jeder Parameter (Generic) in der Komponentendeklaration wird 
mit einem gleichnamigen Parameter der Entity verknüpft. Für 
den Parameterwert wird zuerst auf die GENERIC MAP der Kom- 
ponenteninstantiierung zurückgegriffen. Wurden hier keine Pa- 
rameterwerte angegeben, so gelten die Defaultwerte aus der 
Komponentendeklaration. Falls auch hier keine Werte für die 
Generics definiert sind, gelten die Defaultwerte aus der Entity 
(Default-GENERIC MAP). 


Fehlt die Komponentenkonfigurationsanweisung komplett, so 
wird diejenige Entity (incl. der Default-Architektur, d.h. der zu- 
letzt compilierten Architektur der Entity) eingesetzt, deren Name 
mit dem Namen der Komponente übereinstimmt. Es gelten in 
diesem Fall die Regeln für die Default-GENERIC MAP und die 
Default-PORT MAP. 
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Wird als Komponentenkonfiguration ein Entity-Architecture-Paar an- 
gegeben und handelt es sich bei der beschriebenen Instanz ebenfalls 
um ein strukturales Modell, so muß dieses Modell durch weitere 
Konfigurationsanweisungen eine Ebene tiefer beschrieben werden. 


Anstelle einzelner Instanzennamen (inst_name) können auch die 
Schlüsselwörter OTHERS (alle bisher noch nicht explizit beschriebe- 
nen Instanzen des Komponententyps comp_name) oder ALL (alle 
Instanzen des Typs comp_name) verwendet werden: 


FOR OTHERS : comp_name USE ... ; 
END FOR ; 
FOR ALL : comp_name USE ...; 
END FOR ; 


Zwei Beispiele sollen diese nicht einfache Syntax verdeutlichen. 


Die erste Konfiguration beschreibt den bereits eingeführten Halb- 
addierer (Abb. B-18), dessen Schnittstellenbeschreibung und struktu- 
rale Architektur im nachfolgenden aufgeführt ist. Die Komponenten 
(Sockeltypen) innerhalb dieses Modells tragen die Bezeichner xor2 
und and2. Die beiden Instanzen der Komponenten heißen xor_in- 
stance und and_instance. In diese Instanzen werden zwei Ver- 
haltensmodelle aus der Bibliothek work mit unterschiedlichen Me- 
thoden eingesetzt. Das Modell für die erstgenannte Instanz wird durch 
die Angabe seiner Schnittstellenbeschreibung und seiner Architektur 
referenziert, das Modell für and_instance hingegen durch den 
Verweis auf dessen Konfiguration. 
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xor_instance halfadder 


sig_b sig_y 


De” 


Abb. B-18: Struktur des Halbaddierers 


ENTITY halfadder IS 
PORT (sum_a, sum_b : IN bit; sum, carry : OUT bit ) ; 
END halfadder ; 


ARCHITECTURE structural OF halfadder IS 
-- Komponentendeklarationen 
COMPONENT xor2 
PORT: keT, € &. IN bi: & 2: OU 
END COMPONENT ; 
COMPONENT and2 
PORT Ted, 25-2. IN Dit 26.7 00 
END COMPONENT ; 
BEGIN 


-- Komponenteninstantiierungen 
xor_instance : xor2 PORT MAP (sum_a, sum_b, sum) ; 
and_instance : and2 PORT MAP (sum_a, sum_b, carry) ; 
END structural ; 
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CONFIGURATION ha_config OF halfadder IS 
-- Blockkonfiguration 
FOR structural 
-- Komponentenkonfiguration 
FOR xor_instance: xor2 
USE ENTITY work.exor (behavioral) 
PORT MAP (c1,c2,c3) ; 
D FOR ; 
Komponentenkonfiguration 
R and_instance: and2 
USE CONFIGURATION work.and2_config 
PORT MAP (a => c4, b => c5, y => c6b) ; 
D FOR ; 
R; 
a_config ; 


Das folgende VHDL-Beispiel zeigt eine mögliche Konfiguration für 
die Architektur structural_4 des im Kapitel 5 (Abb. B-6) ein- 
geführten 3-2-AND-OR-INVERT-Komplexgatters. Hier werden De- 
fault-PORT MAP und Default-GENERIC MAP verwendet. Weitere Bei- 
spiele für Konfigurationen können den VHDL-Modellen auf der Dis- 
kette entnommen werden. 


CONFIGURATION aoi_config_4 OF aoci IS 
FOR structural_4 -- Blockkonf. (Architekturauswahl) 

FOR nor_stage -- Blockkonfiguration 

-- Komponentenkonfiguration 

FOR or_c : or2 USE ENTITY work.or2 (behavioral); 

END FOR; 

END FOR; 

FOR and_stage -- Blockkonfiguration 


-- Komponentenkonfigurationen 

FOR and_b : and2 USE ENTITY work.and2 (behavioral); 
END FOR; 
FOR and_a : and3 USE EN Y work.and3 (behavioral); 


END FOR; 
END FOR; 

END FOR; 

D aci_config_4; 
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7.2.3 Konfiguration von Komponenten außerhalb der 
Design-Einheit "Configuration" 


Die Konfiguration von Komponenten kann nicht nur in der Design- 
Einheit "Configuration", sondern auch in der Architektur selbst vorge- 
nommen werden. Die dazu erforderlichen Komponentenkonfigura- 
tionsanweisungen sind im Deklarationsteil derjenigen Ebene anzuge- 
ben, auf der die entsprechenden Komponenteninstantiierungen selbst 
stehen. Dies kann also auch der Deklarationsteil eines Blockes sein. 


Folgende Architektur des 3-2-AND-OR-INVERT-Komplexgatters be- 
nötigt keine eigene Design-Einheit "Configuration": 


ARCHITECTURE structural_6 OF aoi IS 
SIGNAL a_out, b_out, or_out : bit; -- interne Signale 


-- Komponentendeklarationen 


--Komponentenkonfigurationen 

FOR ALL : inv USE ENTITY work.notl (behavioral); 
FOR ALL : or2 USE ENTITY work.or2 (behavioral); 
FOR ALL : and2 E CONFIGURATION work.and2_config; 
FOR ALL : and3 E CONFIGURATION work.and3_config; 
EGIN 


-- Komponenteninstantiierungen 


END structural_6 ; 


7.2.4 Inkrementelles Konfigurieren / 93 


Die VHDL-Syntax in der ursprünglichen Version (Yg7) erlaubt nur 
eine einmalige Konfiguration einer strukturalen Architektur, entweder 
innerhalb der Architektur (oder eines Blockes) oder in einer Konfi- 
guration. Beim ASIC-Entwurf verhindert diese Einschränkung aller- 
dings eine einfache Rückführung von exakten Verzögerungszeiten 
nach der Layouterzeugung (sog. "Backannotation"). Es wäre wün- 
schenswert, die Auswahl des einzusetzenden Modells und die Signal- 
verbindungen von der Zuweisung der Parameter (in diesem Fall: Ver- 
zögerungszeiten) zu trennen. 
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Dies ist nun mit der überarbeiteten Norm (Y’93) möglich. Das sog. 
"incremental binding" erlaubt die Trennung der einzelnen Teile der 
Komponentenkonfiguration. Es sind sogar mehrfache GENERIC 
MAP-Anweisungen möglich. Ein Beispiel erläutert diese Vereinbarung: 


ARCHITECTURE structural_7 OF aci IS -- 11 VHDL'93-Syntax 
SIGNAL a_out, b_out, or_out : bit; 


Komponentendeklarationen 


inheitliche Laufzeiten pro Gattertyp (ALL) 

ALL : i E ENTITY work.notl (behavioral) 
RIC MAP (0.75 ns, 0.7ns) ; 
ENTITY work.or2 (behavioral) 

RIC MAP (1.6 ns, 1.5 ns) ; 
CONFIGURATION work .and2_config ; 
CONFIGURATION work.and3_config ; 


Komponenteninstantiierungen 


END structural_7 ; 


CONFIGURATION aoi_config_7 OF aci IS -- !11 VHDL'93-Syntax 
FOR structural_7 
-- hier koennen instanzenspezifische Laufzeiten stehen 
FOR inv_d : inv GENERIC MAP (0.9 ns, 0.8 ns); END FOR; 
FOR or_c : or2 GENERIC MAP (1.8 ns, ./ns); END FOR; 
FOR and_b : and2 GENERIC MAP (1.3 ns, .9 ns); END FOR; 
FOR and_a : and3 GENERIC MAP (1.A ns, .O ns); END FOR; 

END FOR; 

D acoi_config_7; 


Ein Simulationsaufruf nur mit den Konfigurationen aus der Architek- 
tur verwendet beispielsweise geschätzte Werte oder die Defaultwerte für 
die Verzögerungszeiten. Die Simulation durch Angabe der Konfigura- 
tion aoi_config_7 dagegen weist den Parametern der jeweiligen 
Gatter neue (z.B. aus dem Layout ermittelte) Verzögerungszeiten zu. 
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Da die nebenläufigen Anweisungen i.d.R. auf einem Prozessor, d.h. 
nur "quasi" parallel ablaufen, ist ein spezieller Simulationsablauf nötig, 
der die Nebenläufigkeit von VHDL "nachbildet". 


Dazu sind die Zusammenhänge zwischen nebenläufigen und sequen- 
tiellen Anweisungen und der Unterschied zwischen Signal- und Vari- 
ablenzuweisungen näher zu beleuchten. 


Sequentielle Anweisungen stehen in Prozessen, Funktionen oder Pro- 
zeduren. Funktionen und Prozeduren werden durch spezielle Aufrufe 
aktiviert, die selbst wieder sequentiell oder nebenläufig sind. Prozesse 
gelten als nebenläufige Anweisung. Sie werden durch eine Liste sensi- 
tiver Signale im Prozeß-Kopf oder durch WAIT-Anweisungen inner- 
halb des Prozesses gesteuert. Die Prozesse werden immer dann akti- 
viert und ausgeführt, wenn auf mindestens einem der Signale aus der 
"sensitivity list" ein Ereignis auftritt. Ist keine "sensitivity list" vorhan- 
den, so wird ein Prozeß dadurch reaktiviert, daß die Bedingung der 
WAIT-Anweisung erfüllt wird. 


8.1 Delta-Zyklus 


Während der Simulation schreitet die (Simulations-)Zeit fort, wobei je- 
der Zeitpunkt, an dem Transaktionen eingetragen sind, bearbeitet wird. 
Ein Simulationszeitpunkt besteht dabei im allgemeinen aus mehreren 
Zyklen, die um eine infinitesimal kleine Zeit, mit "Delta" (A) bezeich- 
net, versetzt sind. Jeder dieser Delta-Zyklen besteht wiederum aus zwei 
aufeinanderfolgenden Phasen: 


1. _ Prozeß-Ausführungsphase ("process evaluation"): 
Hierbei werden alle aktiven Prozesse bis zur END-Anweisung 
bzw. bis zur nächsten WAIT-Anweisung abgearbeitet. Dies bein- 
haltet das Ausführen aller enthaltenen Anweisungen bis auf die 
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Signalzuweisungen, also insbesondere auch die Zuweisung von 
Variablen. 


2. Signalzuweisungsphase ("signal update"): 
Nach Ausführung des oder der für dieses "Delta" aktiven Pro- 
zesse werden die in diesen Prozessen zugewiesenen Signalän- 
derungen durchgeführt. Dadurch können weitere Prozesse oder 
nebenläufige Signalzuweisungen aktiviert werden. In diesem Fall 
wird der Zyklus ein "Delta" später wieder von vorne durchlau- 
fen. 


Zu Beginn der Bearbeitung eines Simulationszeitpunktes t„, werden zu- 
nächst die dort vorgesehenen Signalzuweisungen durchgeführt, da- 
nach alle sensitiven Prozesse ausgeführt, um anschließend die von 
diesen Prozessen ausgelösten Signalzuweisungen durchzuführen, usw. 
Dieser Ablauf wird an einem Zeitpunkt t„ solange wiederholt, bis sich 
ein stabiler Zustand einstellt, d.h. bis sich keine neue Signalzuweisung 
mehr ergibt und kein weiterer Prozeß aktiviert wird. Man erhält ein 
Ablaufschema, das in folgender Art und Weise dargestellt werden 
kann: 


process- process- 
evaluation evaluation 
+1A +1 A 
signal- signal- 
\__update \__Uupdate 
t 
tn tn+1 


Abb. B-19: Simulationsablauf 


Es ist an dieser Stelle zu beachten, daß auch die nebenläufigen Anwei- 
sungen als Prozesse interpretiert werden. Letztendlich läßt sich nämlich 
jede nebenläufige Anweisung durch einen äquivalenten Prozeß erset- 
zen. Die Signale auf der rechten Seite einer nebenläufigen Signalzu- 
weisung werden bei dieser Umsetzung in die "sensitivity-list" aufge- 
nommen. Für folgende nebenläufige Signalzuweisung: 
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csa: sig_b <= '1', '0O' AR 


5%, U] AR 
A 


lautet die äquivalente Darstellung als Prozeß: 


csa: PROCI 
EGIN 

IF sel = EN sig_b <= '1', '0' AR 
SIF sel EN sig_b <= '0', '1' AR 
ELSE sig_b <= '2'; 

END IF; 

D P 


Damit wird ersichtlich, daß nebenläufige Signalzuweisungen immer 
durch Ereignisse auf den Signalen der rechten Seite aktiviert werden. 


8.2  Zeitverhalten von Signal- und 
Variablenzuweisungen 


Es sei noch einmal explizit erwähnt, daß Signale zwar beim Abarbeiten 
der entsprechenden sequentiellen Signalzuweisungen projektiert wer- 
den - was soviel heißt wie ein Vormerken des neuen Signalwertes 
("scheduling") - aber erst am Ende des Prozesses oder beim Erreichen 
der nächsten WAIT-Anweisung den neuen Wert annehmen. 


Besondere Beachtung erfordern deshalb Prozesse, die gemischt Vari- 
ablen- und Signalzuweisungen verwenden und gegenseitige Abhän- 
gigkeiten zwischen Variablen und Signalen aufweisen. Auch bei der 
Prozeßkommunikation ist darauf zu achten, daß sich die triggernden 
Signale zum richtigen Zeitpunkt ändern. 


Ein kleines Beispiel soll verdeutlichen, daß Signalzuweisungen inner- 


halb von Prozessen sich nicht wie herkömmliche sequentielle Anwei- 
sungen verhalten: 
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ARCHITECTURE number_one OF example IS 
SIGNAL a, b : integer := 
BEGIN 
a <= 1 AFTER Ins, 2 AFTER 2 ns, 3 AFTER 3 ns; 
PROCESS -- Aufruf bei Ereignis auf Signal a 
VARIABLI : integer := 0; 


B 
b<s=sart2; -- Signalzuweisung 

= 2% b; -- Variablenzuweisung 
END PROCESS; 
D number_one; 


Der Prozeß wird (nach dem initialen Durchlauf) zum Zeitpunkt Ins + 
1A durch ein Ereignis auf dem Signal a getriggert. Das Signal b wird 
erst nach Ende des Prozeßdurchlaufes in der Signalzuweisungsphase 
den Wert 3 erhalten. Zum Zeitpunkt der Variablenzuweisung liegt 
noch der alte Wert von b (2), herrührend von der Initialisierungsphase, 
vor. Die Variable c wird also zum Zeitpunkt I ns + 1A nicht wie er- 
wartet den Wert 6, sondern den Wert 4 annehmen. Der gewünschte 
Wert 6 wird erst beim nächsten Prozeßdurchlauf erreicht; in diesem 
Fall zum Zeitpunkt 2 ns + 1A. 


Dieses Problem kann gelöst werden, indem die arithmetischen Opera- 
tionen nur mit Variablen durchgeführt werden, da diese den neuen 
Wert ohne jegliche Verzögerung annehmen: 


ARCHITECTURE number_four OF example IS 
SIGNAL a : integer := 

BEGIN 
a <= 1 AFTER Ins, 2 AFTER 2 ns, 3 AFTER 3 ns; 
PROCESS -- Aufruf bei Ereignis auf Signal a 


VARIABLE : integer := 0; 


B 
=at 2; -- Variablenzuweisung 
= 2% b; -- Variablenzuweisung 
END PROCESS; 

D number_four; 
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Die Variable b nimmt hier sofort den Wert 3 an, so daß c wie ge- 
wünscht den Wert 6 erhält. 


Alternativ zu dieser Lösung könnte neben a auch das Signal b in die 
"sensitivity-list" des Prozesses aufgenommen werden: 


ARCHITECTURE number_three OF example IS 
SIGNAL a, b : integer := 0; 

BEGIN 
a <= 1 AFTER I ns, 2 AFTER 2 ns, 3 AFTER 3 ns; 
PROCESS (a, b) -- Aufruf bei Ereignis auf Signal a oder b 


VARIABLE c : integer := 0; 
BEGIN 


b<=at 2; -- Signalzuweisung 
2%; -- Variablenzuweisung 

END PROCESS; 

D number_three; 


Der Prozeß wird bei dieser Variante zum Zeitpunkt I ns + 1A zuerst 
durch das Ereignis auf dem Signal a aktiviert. Anschließend aktiviert 
die Änderung des Signals b von 2 auf 3 erneut den Prozeß (bei I ns + 
2A). Beim zweiten Prozeßdurchlauf wird der Wert der Variablen c mit 
dem inzwischen aktualisierten Wert von b richtig berechnet. 


Eine dritte Variante zur Lösung des Problems unter Verwendung von 
WAIT-Anweisungen findet sich auf der beiliegenden Diskette. 


Da Signale nicht im gleichen Delta-Zyklus neu zugewiesen werden 
müssen, auch wenn sie am Ende des Simulationszeitpunktes gleiche 
Werte besitzen, können Assertions, die auf Gleichheit zweier Signale 
prüfen, "falsche" Fehlermeldungen produzieren. 


8.3 Aktivierung zum letzten Delta-Zyklus Yg3 


In 7/93 wurde der Begriff "postponed" im Zusammenhang mit Pro- 
zessen, Prozeduraufrufen, Signalzuweisungen und Assertions einge- 
führt. Er besagt, daß die entsprechend markierten VHDL-Anweisun- 
gen erst im definitiv letzten Delta-Zyklus eines Simulationszeitpunktes 
aktiviert werden. 
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8.3.1 Prozesse 


Die erweiterte Syntax der Prozeßanweisung einschließlich des optiona- 
len Schlüsselwortes POSTPONED lautet nun (93): 


[process_label :] L[POSTPONED] PROCESS 
[(sig_name_l {, sig_name_n})] [IS] 


BEGIN 
END [POSTPONED] PROCESS [process_label] ; 


Die Kennzeichnung eines Prozesses als POSTPONED hat folgende 
Konsequenzen: 


a Da der Prozeß erst zum letzten Delta-Zyklus aktiviert wird, be- 
finden sich alle Signale in einem für diesen Simulationszeit- 
punkt stabilen Zustand. 


m Derartige Prozesse dürfen keine neuen Delta-Zyklen mehr ver- 
ursachen. Dies bedeutet insbesondere: 
O es dürfen keine unverzögerten Signalzuweisungen enthal- 
ten sein. 
O es dürfen keine "WAIT FOR 0 f£s;"-Anweisungen ent- 
halten sein, 
a Falls der Prozeß auf mehrere Signale sensitiv ist, kann im letzten 


Delta-Zyklus durch Attribute wie z.B. EVENT nicht mehr festge- 
stellt werden, welches Signal den Prozeß aktiviert hat. 


8.3.2 Assertions 


Gerade bei Assertions ist es wichtig, daß evtl. zu überprüfende Signale 
einen stabilen Zustand erreicht haben. Unnötige Fehlermeldungen 
werden so vermieden. Bei nebenläufigen Assertions lautet die Syntax 
mit dem Schlüsselwort POSTPONED (V93): 


[assert_label :] [POSTPONED] ASSERT condition 
[REPORT "message_string"] 
[SEVERITY severity_level] ; 
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8.3.3 Signalzuweisungen 


Auch bei nebenläufigen Signalzuweisungen ist eine Verlagerung in 
den letzten Delta-Zyklus durch das Schlüsselwort POSTPONED mög- 
lich. Signalzuweisungen ohne jegliche Verzögerung sind dabei aller- 
dings nicht erlaubt. Die entsprechende Syntax am Beispiel der nicht 
bedingten Signalzuweisung lautet (/93): 


[assignment_label :] L[POSTPONED] sig_name 
<= [TRANSPORT] value_l [AFTER time_l] 
{, value_n AFTER time_n } ; 


8.3.4 Prozeduraufrufe 


Ein weiterer Befehl, der in den letzten Delta-Zyklus verlegt werden 
kann, ist der nebenläufige Aufruf einer Prozedur nach der folgenden 
Syntax mit dem Schlüsselwort POSTPONED (4953): 


[proc_call_label :] 
[POSTPONED] procedure_name 
[(argument_values)] ; 
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Neben den obigen Erläuterungen über nebenläufige und sequentielle 
Signalzuweisungen gibt es noch einige Besonderheiten bei der Hand- 
habung von Signalen in VHDL, die hier erwähnt werden sollen. 


9.1 Signaltreiber und Auflösungsfunktionen 


Ein Signal ist ein Informationsträger, der verschiedene Signalwerte an- 
nehmen kann. Im Falle herkömmlicher Signale, wie sie in vorherge- 
henden Kapiteln erläutert wurden, wird dieser Wert durch Signalzu- 
weisungen festgelegt. Dahinter verbirgt sich aber ein Mechanismus, 
der erst bei mehrfachen, gleichzeitigen Zuweisungen an ein und das- 
selbe Signal wichtig wird: Das Konzept von Signaltreibern und Auf- 
lösungsfunktionen ("resolution functions"). 


Soll z.B. ein Bus oder eine bidirektionale Verbindung aufgebaut wer- 
den, sind jeweils mehrere Signalquellen für ein Signal vorzusehen, die 
in gewisser Weise einen Teil zum resultierenden Signalwert auf dem 
Bus oder der bidirektionalen Leitung beitragen. Diese einzelnen Si- 
gnalquellen werden in VHDL als Signaltreiber ("driver") bezeichnet. 


Signaltreiber werden durch VHDL-Signalzuweisungen erzeugt. Dies 
geschieht oft auch unbeabsichtigt durch mehrfache Signalzuweisun- 
gen. Das Signal w im nachfolgenden Beispiel besitzt durch die beiden 
Signalzuweisungen zwei Signaltreiber, die u.U. auch gleichzeitig aktiv 
sein können, da die Anweisungen nebenläufig (parallel) ablaufen. 


ARCHITECTURE arch_one OF anything IS 
BEGIN 
w <= y AFTER 25 ns WHEN sel = 
w <= z AFTER 30 ns WHEN sel = 
END arch_one ; 
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Bei mehreren gleichzeitig aktiven Signaltreibern ist es möglich, daß 
von den einzelnen Treibern unterschiedliche Signalwerte zugewiesen 
werden. Solche Fälle werden durch die sog. Auflösungsfunktionen ge- 
regelt. Abb. B-20 zeigt schematisch die Aufgabe dieser Funktionen: 


Zu Zu 


Zu Zu 


Abb. B-20: Wirkung von Auflösungsfunktionen 


Bei Deklaration eines eigenen Logiktyps und Verwendung mehrfacher 
Treiber muß auch die entsprechende Auflösungsfunktionen beschrie- 
ben werden. Bei der Deklaration werden alle Signale und Ports ge- 
kennzeichnet, auf die eine solche Funktion angewandt werden soll; 
man spricht dann von aufgelösten Signalen (sog. "resolved signals"). 
Dies kann auf zwei Arten erfolgen: 


I durch Deklaration eines Untertyps (res_type_name), der 
vom Basistyp (unres_type_name) durch Angabe der 
Auflösungsfunktion (res_fct_name) abgeleitet wird: 


SUBTYPE res_type_name 
IS res_fct_name unres_type_name ; 
SIGNAL res_sig_name_l {, res_sig_name_n} 
res_type_name [:= def_value] ; 


m durch Deklaration des Signals direkt unter Angabe der Auflö- 
sungsfunktion: 


SIGNAL res_sig_name_l {, res_sig_name_n} 
res_fct_name unres_type_name 
[:= def_value] ; 
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Die Auflösungsfunktion wird bei jeder Signalzuweisung implizit auf- 
gerufen und berechnet den neuen Signalwert aus den Beiträgen der 
einzelnen Treiber. Theoretisch können alle verwendeten Ports und Si- 
gnale mit aufgelöstem Typ deklariert werden. Der implizite Aufruf der 
entsprechenden Funktion bei jeder Signalzuweisung erhöht die Si- 
mulationszeit jedoch ganz erheblich. 


Auflösungsfunktionen müssen beliebig viele Treiber berücksichtigen 
können und einen Defaultwert zurückliefern, falls keiner der Treiber 
aktiv einen Signalpegel erzeugt (siehe nachfolgenden Abschnitt über 
kontrollierte Signale und DISCONNECT-Anweisung). 


Am Beispiel einer 4-wertigen Logik mv1l4 mit den möglichen 
Signalwerten 'x', '0','1', "2" soll das typische Vorgehen bei der 
Deklaration von aufgelösten Signalen und Auflösungsfunktionen er- 
läutert werden: 


PACKAGE fourval IS 
TYPE mvl4 IS ('x', '0', '1'!, 'Z'); 
TYPE mvl4_vector IS ARRAY (natural RANGE <>) OF mvl4; 


FUNCTION resolved (a: mvl4_vector) RETURN mvl4; 

SUBTYPE mvl4_r IS resolved mvl4; 

TYPE mvl4_r_vector IS ARRAY (natural RANGE <>) OF mvl4_r; 
END fourval; 


Nach Deklaration des Basistyps mv14 und des entsprechenden Vek- 
tors mvl4_vector wird die Funktion resolved bekanntgegeben. 
Ihre Funktionalität wird im nachfolgend aufgeführten Package Body 
beschrieben. Daraufhin kann ein aufgelöster Untertyp mvl4_r ab- 
geleitet werden. Der aufgelöste Vektortyp mvl4_r_vector besteht 
wiederum aus aufgelösten Einzelelementen. 
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PACKAGE BODY fourval IS 
FUNCTION resolved (a: mvl4_vector) RETURN mvl4 IS 
VARIABLE result : mvl4 := '2'; 
-- Defaultwert: 'Z2': schwaechster Logikwert 
EGIN 
FOR m in a'RANGE LOOP 
IF a(m) = 'X' OR 
(a (m) '1' AND result = 
(a(m) = '0' AND result = ) ETURN 'X'; 
ELSIF 
(a (m) '0' AND result = 
(a(m) = '1' AND result 
result := a(m); 
END IF; 
END LOOP; 
RI RN result; 
END resolved; 
D fourval; 


Folgendes Beispiel zeigt die Anwendung des Typs mvl4_r: 


ENTITY resolve IS 
PORT (sel : IN positive; x: OUT mvl4_r); 
END resolve; 


ARCHITECTURE behavioral OF resolve IS 
BEGIN 

x <= '0' WHEN sel = BE... 

x <= '1' WHEN sel = 2 BR; 

END behavioral; 


Falls sel auf 2 wechselt, würde die Auflösungsfunktion resolved 
für das Signal x den Wert '1' aus den beiden konkurrierenden Wer- 
ten '1' und '2' bestimmen. Wechselt sel dagegen auf 1, so ergibt 
sich der Wert 'x' für das Signal x. 


Das explizite Abschalten eines einzelnen Treibers für ein aufgelöstes 
Signal Kann unter Kenntnis der Auflösungsfunktion durch Angabe 
des Defaultwertes (in diesem Fall '2"') erfolgen: 
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ARCHITECTURE behavioral OF demo IS 
BEGIN 
y <= '1'! AFTER 5ns, -- aktive '1' treiben 

'Z' AFTER 40 ns ; -- 'Z' entspricht Abschalten 
END behavioral ; 


9.2 Kontrollierte Signalzuweisungen 


VHDL bietet neben den bedingten Zuweisungen eine weitere Mög- 
lichkeit, Signalzuweisungen zu steuern, die sog. kontrollierten Signal- 
zuweisungen ("guarded signal assignment"). Dies sind nebenläufige 
Signalzuweisungen, die durch das Schlüsselwort GUARDED gekenn- 
zeichnet werden: 


[label :] sig_name <= GUARDED sig_waveform ; 


Die kontrollierende Bedingung, die erfüllt sein muß, damit solche Si- 
gnalzuweisungen auch durchgeführt werden, nennt man "guard_ 
expression". Die dadurch kontrollierten Signalzuweisungen müs- 
sen innerhalb eines Blockes stehen, der die Kontrollbedingung im 
Blockrahmen enthält. Die entsprechende Blocksyntax lautet: 


block_label : BLOCK (guard_expression) 
BEGIN 
END BLOCK ; 


Dieses Konstrukt wird durch den VHDL-Compiler in eine äquivalente 
IF-Anweisung umgewandelt: 


IF guard_expression THEN 
sig_name <= sig_waveform ; 
END IF ; 


Diese Anweisung steht in einem äquivalenten Prozeß mit gleichem 
Label (olock_label), der eine entsprechende WAIT ON-Anwei- 
sung am Ende mit allen Signalen enthält, die im vorgesehenen Signal- 
verlauf (sig_waveform) oder in der Bedingung (guard_ex- 
pression) auftreten. 
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Mit kontrollierten Signalzuweisungen kann z.B. auch die Funktionali- 
tät des bereits erwähnten D-Latch realisiert werden: 


ECTURE concurrent_5 OF latch IS 


EGIN 
 assignment : BLOCK (clk = '1') 
EGIN 
q <= GUARDED d; 
END BLOCK; 

END concurrent_5; 


9.3  _Kontrollierte Signale 


Die im vorhergehenden Abschnitt besprochenen kontrollierten Signal- 
zuweisungen arbeiten mit herkömmlichen Signalen. Werden die in 
solchen Anweisungen neu zugewiesenen Signale aber explizit als kon- 
trollierte Signale ("guarded signals") deklariert, so erfolgt bei einer 
nicht erfüllten guard_expression das Abschalten des entsprech- 
enden Signaltreibers. 


Die Kennzeichnung eines Signals als kontrolliertes Signal erfolgt 
durch zusätzliche Angabe eines der Schlüsselwörter REGISTER oder 
BUS bei der Deklaration. Kontrollierte Signale müssen einen aufgelö- 
sten Typ besitzen: 


SIGNAL sig_name_l {, sig_name_n} 
res_type_name REGISTER [:= def_value] ; 


SIGNAL sig_name_l {, sig_name_n} 
res_type_name BUS [:= def_value] ; 


Auf solche Signale angewandte kontrollierte Signalzuweisungen haben 
folgende Bedeutung (gezeigt anhand der äquivalenten IF-Anwei- 
sung): 


IF guard_expression THEN 
sig_name <= sig_waveform ; 


ELSE 
sig_name <= NULL ; 
END IF ; 


198 © G. Lehmann/B. Wunder/M. Selz 


9 Besonderheiten bei Signalen 


Die Zuweisung von NULL auf das Signal bedeutet nichts anderes, als 
daß der Treiber dieser Signalzuweisung abgeschaltet wird. Für das re- 
sultierende (aufgelöste) Signal hat dies folgende Konsequenzen: 


A Wurden nicht alle Treiber abgeschaltet, so wird das resultierende 
Signal nur anhand der nicht abgeschalteten Treiber ermittelt, 


I wurden alle Treiber abgeschaltet, so wird im Falle der Signal- 
deklaration als REGISTER der zuletzt vorhandene Signalwert 
beibehalten, 


m wurden alle Treiber abgeschaltet, so wird im Falle der Signal- 
deklaration als BUS der in der "resolution function" angegebene 
Defaultwert angenommen. 


Das Abschalten des Signaltreibers erfolgt unmittelbar, d.h. ohne Ver- 
zögerung, nachdem die guard_expression den Wert false an- 
genommen hat, es sei denn, es wurde für das Signal im Anschluß an 
dessen Deklaration als kontrolliertes Signal eine explizite Verzöge- 
rungszeit (time_expr) durch die sog. DISCONNECT-Anweisung 
vereinbart: 


DISCONNECT sig_name_l {, sig_name_n} 
res_type_name AFTER time_expr ; 


DISCONNECT OTHERS 
res_type_name AFTER time_expr ; 


DISCONNECT ALL 
res_type_name AFTER time_expr ; 


Jedes kontrollierte Signal darf nur eine DISCONNECT-Anweisung er- 
halten. Die Schlüsselwörter OTHERS und ALL beschreiben alle noch 
nicht explizit mit einer Abschaltverzögerung versehenen bzw. alle Si- 
gnale des aufgelösten Typs res_type_name. 
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Die Handhabung von kontrollierten Signalen soll anhand eines Bei- 
spiels verdeutlicht werden: 


USE work.fourval.ALL; 
ENTITY mux_2_1 IS 
PORT (in_signals : IN mvl4_vector (1 TO 2); 
choice : IN integer; 
out_signal : OUT mvl4_r BUS ); 
END mux_2_1; 


ARCHITECTURE with_qguards OF mux_2_1 IS 
DISCONNECT out_signal : mvl4_r AFTER 25 ns; 
BEGIN 


choice_1l : BLOCK (choice = 1) 

BEGIN 

out_signal <= GUARDED in_signals (1) AF 
END BLOCK; 


choice_2 : BLOCK (choice = 2) 

EGIN 

out_signal <= GUARDED in_signals (2) AFTER 18 ns; 
END BLOCK; 


D with_guards; 


Wechselt das Eingangssignal choice auf 1, so wird der Signaltreiber 
des ersten Blockes aktiv und gibt das erste Eingangssignal nach 20 ns 
an den Ausgang weiter. Wechselt choice auf 2, so wird durch den 
zweiten Block das zweite Eingangssignal nach 18 ns ebenfalls auf den 
Ausgang gelegt. Da der erste Signaltreiber aber erst nach 25 ns ab- 
schaltet, sind für 7 ns zwei Treiber aktiv. Das resultierende Signal wird 
durch die Auflösungsfunktion ermittelt. Wechselt choice auf einen 
Wert ungleich 1 oder 2, so schaltet der zuletzt aktive Treiber nach 25 
ns ab und das Ausgangssignal wechselt in den Defaultwert (in diesem 
Falle 'z2'), daes als BUS deklariert ist. Bei einer Deklaration als 
REGISTER würde der letzte Signalwert erhalten bleiben. 
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Um bei großen Entwürfen die Übersicht über die Vielzahl von auftre- 
tenden Objekten, Typen, Unterprogrammen usw. nicht zu verlieren, ist 
es sinnvoll, eine eindeutige Struktur der Namensgebung einzuführen 
und konsequent beizubehalten. Dafür soll ein Blick auf die Regeln 
geworfen werden, nach denen entschieden wird, ob ein Objekt in einer 
Anweisung verwendet werden kann und welches VHDL-Element ef- 
fektiv zum Einsatz kommt. 


10.1 Gültigkeit 


Der Gültigkeitsbereich eines Objektes oder eines VHDL-Elementes 
hängt im wesentlichen vom Ort der Deklaration ab und umschließt alle 
hierarchisch tieferliegenden Design- und Syntax-Einheiten nach fol- 
gender Schichtung: 


I Deklarationen im Package gelten für alle Design-Einheiten, die 
das Package verwenden. 


I Deklaration im Deklarationsteil einer Entity gelten für alle dieser 
Entity zugehörenden Architekturen und die darin enthaltenen 
Blöcke und Anweisungen. 


A Deklaration im Deklarationsteil einer Architektur haben für alle 
enthaltenen Blöcke und Anweisungen Gültigkeit. 


I Erfolgt die Deklaration in einem Block, so umfaßt der Gültig- 
keitsbereich alle im Block enthaltenen Anweisungen. 


I Deklaration innerhalb eines Prozesses gelten nur für die im Pro- 
zeß enthaltenen Anweisungen. 


A Deklarationen in einer Schleife (Laufvariable) oder im Deklara- 
tionsteil einer Funktion bzw. einer Prozedur haben nur die ein- 
geschränkte Gültigkeit für diese spezielle Anweisung. 
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10.2 Sichtbarkeit 


Entscheidend dafür, ob ein VHDL-Element in einer Anweisung ver- 
wendet werden kann ist, ob es am Ort des Auftretens sichtbar ist. 
Sichtbarkeit bedeutet dabei entweder direkte Sichtbarkeit oder Sicht- 
barkeit durch Auswahl. 


10.2.1 Direkte Sichtbarkeit 


Der Bereich, in dem VHDL-Elemente direkt sichtbar sind, umfaßt in 
der Regel ihren Gültigkeitsbereich nach der Deklaration, es sei denn, 
das VHDL-Element ist verborgen. 


Verborgenheit liegt vor, falls an einer Stelle mehrere gleichartige, gül- 
tige VHDL-Elemente existieren, die an hierarchisch verschiedenen Or- 
ten deklariert wurden. In diesem Fall maskiert oder verbirgt das lokal 
(hierarchisch niedriger) deklarierte VHDL-Element die anderen. 


Sind gleichzeitig mehrere VHDL-Elemente mit gleichem Namen 
direkt sichtbar, werden die Regeln der Überladung (siehe Kapitel 11) 
angewandt. Treffen die Regeln der Überladung nicht zu, kann die 
Anweisung nicht ausgeführt werden. 


10.2.2 Sichtbarkeit durch Auswahl 


Nicht direkt sichtbare VHDL-Elemente können durch die evtl. hier- 
archische, vorangestellte Angabe des Deklarationsortes (nach den Re- 
geln der sog. "selected names") angesprochen werden. Das Zeichen 
zur Trennung zwischen Prefix und eigentlichem Namen ist der Punkt. 


"Selected names" werden nach folgender Syntax, z.B. für Objekte ei- 
nes Packages, für Design-Einheiten aus einer Bibliothek oder für Re- 
cord-Elemente verwendet: 


lib_name.pack_name.obj_name_in_pack 
lib_name.design_unit_name 
record_name.record_element_name 


Um bestimmte Elemente / Funktionen aus Packages oder Design-Ein- 
heiten aus Bibliotheken lokal ohne vollständigen Deklarationspfad an- 
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sprechen zu können, kann die USE-Anweisung auch innerhalb der 
Deklarationsanweisungen von Architekturen, Blöcken, Prozessen, usw. 
stehen. 


Weitere Hinweise zur Sichtbarkeit von Bibliotheken und Packages fin- 
den sich im Abschnitt zu den LIBRARY- und USE-Anweisungen. 


PACKAGE p IS 
CONSTANT c : integer 
END p; 


ENTITY e IS 
CONSTANT c : integer : r -- in ARCH. zu e bekannt 
END e; 


ARCHITECTURE a OF e IS 
SIGNAL s1,s2,s3,s4,s5,s6,s7 : integer : 
BEGIN 
-- PACKAGE p hier nicht bekannt: sel.name work.p.c noetig 
s6 <= work.p.c ; benutzt c aus PACKAGE p : i 
s7 <= c; benutzt c aus ENTITY e: 2 
b : BLOCK 
CONSTANT c : integer := 3; 
BEGIN 
s3 <= c; benutzt c aus 
x : PROCESS 
CONSTANT c : integer := 4; 
E work.p; -- mache PACKAGE p lokal 


s4A <= c; -- benutzt c aus PROCESS 

1 : FOR c IN 5 TO 5 LOOP 
sl <= p.c; -- benutzt c aus PACKAGE 
s2 <= e.c; -- benutzt c aus ENTITY 
s5 <= c; -- benutzt c aus LOOP 

END LOOP; 

WAIT; 

END PROCESS; 

D BLOCK; 
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In diesem Kapitel sollen VHDL-Konstrukte und Modellierungstechni- 
ken erläutert werden, die bei einfachen Aufgabenstellungen in der Re- 
gel nicht benötigt werden. Es richtet sich deshalb vorwiegend an den 
fortgeschrittenen VHDL-Anwender. 


11.1 Benutzerdefinierte Attribute 


Neben den vordefinierten Attributen können auch vom Benutzer Attri- 
bute vergeben werden. Diese können allerdings im Gegensatz zu den 
vordefinierten Attributen nur konstante Werte besitzen. 


Benutzerdefinierte Attribute können nicht nur für Signale, Variablen 
und Konstanten vergeben werden, sondern auch für die Design-Ein- 
heiten (Entity, Architecture, Configuration, Package) und weitere 
VHDL-Elemente wie Prozeduren, Funktionen, Typen, Untertypen, 
Komponenten und sogar für Labels. 


Mit Hilfe von Attributen können diesen verschiedenen Elementen zu- 
sätzliche Informationen mitgegeben werden, die sich mit den bisher 
eingeführten VHDL-Konstrukten nicht abbilden lassen. Beispielsweise 
können einer Architektur Angaben über die maximalen Gehäuseab- 
messungen, den Bauteillieferanten oder die erwarteten Herstellungs- 
kosten zugeordnet werden. 


Ein bedeutendes Anwendungsgebiet für benutzerdefinierte Attribute 
ist die VHDL-Synthese. Hier lassen sich mit programmspezifischen 
Attributen Vorgaben zur Zustandscodierung oder Pfadlaufzeit festle- 
gen. Während der VHDL-Simulator diese Attribute nicht weiter bear- 
beitet, werden sie vom Synthesewerkzeug erkannt und entsprechend 
umgesetzt. 
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Gegenüber Kommentaren bietet die Verwendung von Attributen den 
Vorteil der strengen Typüberwachung und die Möglichkeit, den Attri- 
butwert mit Hilfe des Attributnamens (wie bei den vordefinierten Attri- 
buten) in den VHDL-Modellen abzufragen. 


Bevor das Attribut einem VHDL-Element zugewiesen und mit einem 
Wert versehen werden kann, muß zunächst eine Attributdeklaration 
erfolgen. 


Deklaration von Attributen 
Attributdeklarationen haben folgendes Aussehen: 


ATTRIBUTE attribute_name : type_name ; 


Der Typ des Attributs (type_name) kann ein vordefinierter oder ein 
eigendefinierter Typ sein. 


Definition von Attributen 


Die Verknüpfung des Attributs mit einem oder mehreren Elementen 
unter gleichzeitiger Wertzuweisung geschieht durch Angabe des ent- 
sprechenden VHDL-Elements (element_type: Konstante, Varia- 
ble, Signal, Entity, ... Label) mit Hilfe folgender Anweisung: 


ATTRIBUTE attribute_name OF element_name_l 
{, element_name_n} 
element_type IS attribute_value ; 


Anstelle der Elementnamen (oder Labels von bestimmten Anweisun- 
gen) sind auch die Schlüsselwörter OTHERS und ALL möglich. 


Vordefinierte Attribute können auf diese Weise nicht mit neuen Wer- 
ten belegt werden; sie werden ausschließlich vom Simulator belegt und 
können nur abgefragt werden. 


Anwendung von Attributen 


Die benutzerdefinierten Attribute können in der gleichen Art und 
Weise wie die vordefinierten Attribute abgefragt werden: 


element_name'attribute_name 
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ENTITY attr_demo IS 
-- Typdeklarationen 
YPE level IS (empty, medium, full); 

YPE state IS (instabil, stabil); 

YPE res_type IS RANGE 0.0 TO 1.0E6; 

YPE loc_type IS RECORD x_pos : integer; 
y_pos : integer; 

END RECORD; 

-- Attributdeklarationen 
RIBUTE technology ı string; 
RIBUTE priority : level; 
RIBUTE sig_state ı state; 
RIBUTE resistance I. res type; 
RIBUTE location : loc_type; 
Attributdefinition 
RIBUTE technology OF attr_demo : ENTITY IS "tt!"; 
ttr_demo; 


ARCHITECTURE demo OF attr_demo IS 
SIGNAL in_a, in_b, in_c : bit 
-- Attributdefinition 
ATTRIBUTE sig_state OF in_a : SIGNAL IS instabil; 
ATTRIBUTE sig_state OF OTHERS : SIGNAL IS stabil; 

EGIN 


-—- Attributanwendung 
ASSERT attr_demo'technology = "cmos" 
REPORT "Kein CMOS-Modul" SEVERITY note; 


END demo; 


Die neue Norm (93) erlaubt, daß jede Anweisung - auch sequentielle 
- ein Label erhalten kann. Somit kann nahezu jede Zeile aus dem 
VHDL-Quelltext mit einem Attribut versehen werden. 


Ebenso können in Vg3 Gruppen mit Attributen belegt werden. 


206 © G. Lehmann/B. Wunder/M. Selz 


11 Spezielle Modellierungstechniken 


11.2 Gruppen 93 


Mit der Überarbeitung der Norm wurde auch der Begriff der Gruppe 
in die Sprache eingeführt. Mehrere Objekte, Design-Einheiten und 
Unterprogramme können in einer Gruppe zusammengefaßt und ge- 
meinsam mit Attributen dekoriert werden. Gruppenelemente können 
alle mit Namen versehene VHDL-Elemente sein (siehe auch Auf- 
zählung bei den benutzerdefinierten Attributen; in /g93 kommen dazu 
noch LITERAL, UNITS, GROUP und FILE). 


Da auch Labels in eine Gruppe aufgenommen werden Können, lassen 
sich z.B. Prozesse oder nebenläufige Signalzuweisungen, die mit ei- 
nem Label versehen sind, in Gruppen zusammenfassen. 


Typdeklaration von Gruppen 


Bevor man jedoch konkrete Gruppen bildet, muß ähnlich wie bei her- 
kömmlichen Objekten, in einer Deklaration der Gruppentyp festgelegt 
werden: 


GROUP group_type_name IS 
( element_l1_type [<>] 
{ , element_n_type [<>] } ); 


Die optionale Angabe der Zeichen <> bedeutet, daß beliebig viele Ele- 
mente des genannten Typs auftreten können. Beispiele: 


GROUP path IS (SIGNAL, SIGNAL); -- Pfad: 2 Signale 


GROUP pins IS (SIGNAL <>); -- Pins: beliebig 
-- viele Signale (<>) 


Deklaration von Gruppen 


Nachdem der Gruppentyp bekanntgegeben wurde, können in der 
Gruppendeklaration konkrete VHDL-Einheiten zu einer Gruppe zu- 
sammenfügt werden. 
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Die Syntax für die Deklaration einer Gruppe lautet: 


GROUP 


group_name 


: group_type_name 
( group_element_1 { 


4 


group_element_n } ); 


Anzahl und Typen der Gruppenelemente müssen dabei der Typdekla- 
ration entsprechen. 


Anwendung von Gruppen 


Ein Anwendungsgebiet für Gruppen kann z.B. die Angabe von Verzö- 
gerungszeiten einer Gruppe path, die aus zwei Signalen besteht, mit 
Hilfe von benutzerdefinierten Attributen sein: 


ENTITY dlatch_93 IS 


PORT (d, clk : IN ki 
g, gbar : OUT bi 


UP 
UP 
UP 


th IS (SIGNAL, 


| to_q : pa 


to_gbar 
lk_to_q : 
lik_to_gbar : 


RIBUTI 


RIBUTI 


propagation 


RIBUTI 


propagation 


RIBUTI 


propagation 


A 


RIBUTI 
END dlatch_93; 


propagation 


ECTUR 


(d, clk) 


IF clk'EVENT AND clk 
<= d AFTER clk_to_q'propagation; 
gbar <= d AFTER clk_to_gbar'propagation; 


q 


ELSIE 


d'EVENT THEN 


EN! 
D 
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q 


gbar <= d AF 
END IF; 

D PROCESS; 
with_path_attributes; 


ur 


L); 


SIGNAL 


time; 


); 


OF d_to_q , 
OF d_to_gbar : GROUP 


OF clk_to_q 


th (d, q); 
th (d, gbar); 
th (clk, a); 
th (clk, gbar); 
propagation : 


-—- 11 VHDL'93-Syntax !!! 


GROUP 


GROUP 


OF clk_to_gbar : GROUP 


= ']! 


TH 


EN 


E with_path_attributes OF dlatch_93 IS 
-- 11 VHDL'93-Syntax !!! 


<= d AFTER d_to_q'propagation; 


ER d_to_gbar'propagation; 
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11.3 Überladung 


Ein Punkt, der erneut die Verwandtschaft von VHDL mit höheren Pro- 
grammiersprachen zeigt, ist die Möglichkeit zur Überladung ("over- 
loading") von: 


I Unterprogrammen (Funktionen und Prozeduren), 


I Operatoren und 


71 Werten von Aufzähltypen. 


Unter Überladung versteht man die gleichzeitige Sichtbarkeit von 
mehreren gleichnamigen Unterprogrammen, Operatoren bzw. von Ob- 
jektwerten die zu unterschiedlichen Aufzähltypen gehören können. 
Mit Hilfe der Überladung gelingt es beispielsweise, den Anwendungs- 
bereich einer Funktion zu vergrößern. 


Die verschiedenen Varianten eines Unterprogramms oder eines Opera- 
tors unterscheiden sich nur in Anzahl und Typ ihrer Argumente und 
Ergebnisse. VHDL-Programme erkennen aus dem Kontext heraus 
(d.h. aus der Argumentzahl und deren Typen), welche der sichtbaren 
Varianten anzuwenden ist. Ist diese Entscheidung nicht eindeutig, d.h. 
sollten sich mehrere sichtbare Alternativen als "passend" für die zu er- 
füllende Aufgabe erweisen, erfolgt die Ausgabe einer Fehlermeldung. 


Durch das Konzept der Überladung werden VHDL-Modelle übersicht- 
licher, da nicht für jede Variante einer bestimmten Funktionalität ein 
neuer Bezeichner vergeben werden muß. 


11.3.1 Überladen von Unterprogrammen 
Verschiedene Unterprogramme mit gleichem Namen, aber unter- 


schiedlichem Verhalten, werden wie gewöhnlich deklariert. Dies gilt 
gleichermaßen für Prozeduren und Funktionen. Ein Beispiel: 
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ENTITY overload IS 

Bestimmung des Maximums von zwei integer-Werten 
UNCTION max (a_i, b_i : integer) RETURN integer IS 
EGIN 
IF a_i >= b_i THEN RETURN a_i; 
ELSE RETURN b_i; 
END IF; 
END max; 
----- Bestimmung des Maximums von drei integer-Werten 
FUNCTION max (a_i, b_i, c_i : integer) RETURN integer 
BEGIN 
IF a_i >= b_i AND a_i >= c_i THEN RETURN a_i; 
ELSIF b_i >= a_i AND b_i >= c_i THEN RETURN b_i; 
ELSE RETURN c_i; 
END IF; 
END max; 
----- Bestimmung des Maximums von zwei real-Werten 
FUNCTION max (a_r, b_r : real) RETURN real IS 
BEGIN 
IF a_r >= b_r THEN RETURN a_r; 
ELSE RETURN b_r; 
END IF; 
END max; 
----- Bestimmung des Maximums von drei real-Werten 
FUNCTION max (a_r, b_r, c_r : real) RETURN real IS 
BEGIN 
IF a_r >= b_r AND a_r >= c_r EN RETURN a_r; 
ELSIEbr>eir AB br >cenr EN RETURN b_r; 
FLSE RETURN c_r; 
END IF; 
END max; 
D overload; 


Die vier Funktionen max seien in einer Architektur gleichzeitig sicht- 
bar. Für jeden Funktionsaufruf von max wählt das VHDL-Programm 
die Variante aus, die in folgenden Punkten dem Aufruf entspricht: 


Zahl der Argumente, 
Typen der Argumente, 


Namen der Argumente (bei "named association"), 


e®®® 


Typ des Rückgabewertes. 
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Folgendes Beispiel zeigt die Anwendung der oben beschriebenen, 
mehrfach überladenen Funktion max: 


E behavioral OF overload IS 


: real : 
: integer : 


max(3.2, 2.1); -- 3. Variante von max, a = 
maxl1, 2, 3); -- 2. Variante von max, b = 
max(0, 9); -- 1. Variante von max, cC 

= max(real (6), 4.3, 2.1); -- 4. Var. von max, 


END PROCESS; 
D behavioral; 


Besitzen bei einem Funktionsaufruf mehrere Varianten Gültigkeit, so 
verbirgt die lokal deklarierte Variante (z.B. im Deklarationsteil der 
Architektur) die hierarchisch höher deklarierte Variante (z.B. aus ei- 
nem Package). Mit vollständiger hierarchischer Angabe des Unter- 
programmnamens (durch "selected names") kann trotzdem auf die ge- 
wünschte Variante zugegriffen werden. 


11.3.2 _ Überladen von Operatoren 


Operatoren unterscheiden sich von einfachen Funktionen durch zwei 
Punkte: 


m Der Name bzw. das Symbol von Operatoren gilt nicht als "nor- 
maler" Bezeichner, sondern ist eine Zeichenkette (String) und 
steht deshalb bei der Deklaration in Anführungsstrichen. 


m Die Operanden stehen beim üblichen Aufruf eines Operators vor 
bzw. nach dem Operator selbst (bei unären Operatoren nur da- 
nach) und nicht in nachgestellten runden Klammern. Opera- 
toren können aber auch in der Syntax normaler Funktionsauf- 
rufe angesprochen werden: 


"c <= a AND b;" entspricht "c <= "AND" (a,b);" 
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Die Handhabung von Operatoren als String ist bei der Deklaration von 
überladenen Operatoren zu beachten. Ansonsten entspricht diese dem 
Überladen von Funktionen und Prozeduren. Folgendes Beispiel zeigt 
die Überladung des "="-Operators. Bei Verwendung des Packages 
fourval sind damit drei Varianten des "="-Operators verfügbar: Die 
Variante [O0] stellt den vordefinierten Operator "=" dar, welcher ein 
Ergebnis vom Typ boolean zurückliefert. Die beiden benutzer- 
definierten Varianten [1], [2] dagegen vergleichen zwei Werte vom 
Typ mv14 und errechnen ein Ergebnis vom Typ bit bzw. mvl4. 


PACKAGE fourval IS 
TYPE mvl4 IS ('x', '0', '1', 'Z'); 
-- Variante [0]: vordefinierter Operator "=" 
-- FUNCTION "=" (a,b : mvl4) RETURN boolean; 
-- Variante [1]: eigene Definition des Operators "=" 
FUNCTION "=" (a,b : mv14) RETURN bit; 
-- Variante [2]: eigene Definition des Operators "=" 
FUNCTION "=" (a,b : mv14) RETURN mv14; 
END fourval; 


Di 
Di 


PACKAGE BODY fourval IS 
FUNCTION "=" (a, b : mvl4) ETURN bit IS 
VARIABLE result 


B 
IF (a '1' AND 
(a = 'X' AND 
THEN result 
END IF; 
URN result; 
END "="; 


UNCTION "=" (a, b: ETURN mv1l4 

VARIABLE result : = '0'; 

EGIN 

IF (a = '1' AND = OR (a 

(a = 'X' AND = OR (a = 
THEN result 

END IF; 

RETURN result; 

END "="; 

D fourval; 
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11.3.3 _ Überladen von Aufzähltypwerten 


Neben Unterprogrammen und Operatoren können auch die einzelnen 
Werte eines Aufzähltyps überladen werden. Man denke z.B. an den Si- 
gnalwert '0"' des Logiktyps bit und die '0"' des benutzerdefinier- 
ten Logiktyps mv1l4. Tritt ein Ausdruck mit solchen Werten im 
VHDL-Quelltext auf, so muß aus dem Kontext heraus klar sein, um 
welchen Typ es sich dabei handelt. Kann dies nicht eindeutig festge- 
stellt werden, so ist eine explizite Typkennzeichnung erforderlich. 


11.3.4 Explizite Typkennzeichnung 


Bei mehrdeutigen Ausdrücken (s.o.) und Typen von Operanden ist die 
explizite Kennzeichnung des gewünschten Typs durch sog. qualifi- 
zierte Ausdrücke ("qualified expressions") erforderlich. Unter Angabe 
des Typ- bzw. Untertypnamens haben sie folgende Syntax: 


type_name' (expression) 


Eine mögliche Konstellation für die Notwendigkeit eines solchen Kon- 
struktes zeigt folgendes Beispiel. Hier wird durch die Typkennzeich- 
nung explizit angegeben, welche Variante des mehrfach überladenen 
Vergleichsoperators "=" zu verwenden ist. 


USE work.fourval.ALL; -- siehe oben 
ENTITY equal IS 
PORT (a,b,c,d : IN mvl4; 
wi: OUT mvl4; x,y,2Z : OUT boolean ); 


END equal; 


ARCHITECTURE behavioral OF equal IS 
EGIN verw. Funktion in 
(a (e = d; (a [2] b) [2] 
= (a = = mvl4'(c = : [21 5) 701 
(a bit'(c = ; [1] &) [0] 
= (a = boolean' (c : [0] b) [0] 
behavioral; 
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11.4 PORT MAP bei strukturalen Modellen 


Mit Hilfe von PORT MAP-Anweisungen können Signale auf unter- 
schiedlichen Ebenen auf verschiedene Arten miteinander verbunden 
werden. 


PORT MAP-Anweisungen können an verschiedenen Stellen auftreten: 


m) 


In der Design-Einheit "Configuration" verbinden sie "formals" 
(Ports der instantiierten Entity) mit "locals" (Ports der Kompo- 
nente). 


In der Anweisung zur Komponenteninstantiierung verbinden sie 
"locals" (Ports der Komponente) mit "actuals” (Signale in der 
Architektur). 


Für den erstgenannten Fall sollen einige Aspekte der PORT MAP auf- 
gezeigt werden, die auch für Komponenteninstantiierungen gelten: 


m) 


Im einfachsten Fall werden durch eine mit Kommata getrennte 
Liste von "local"-Portnamen beide Signalebenen (in der gleichen 
Reihenfolge wie in der Komponentendeklaration angegeben) 
miteinander verbunden (sog. "positional association"). 


Explizites Zuweisen von Signalen mit dem Zuweisungszeichen 

"=>" eröffnet weitaus mehr Möglichkeiten (sog. "named asso- 

ciation"): 

O Signale können in unterschiedlicher Reihenfolge mit- 
einander verknüpft werden, 


(9) "formal"-Ports können unbeschaltet bleiben (Schlüssel- 
wort OPEN). In diesem Fall muß ein "formal"-Port mit 
dem Modus IN einen Defaultwert besitzen, 


(®) ein "local"-Port kann mit mehr als einem "formal"-Port 
verknüpft werden. 


In Abb. B-21 sind die erlaubten Konstellationen dargestellt. 
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Entity formal 
Komp.-instanz local 
Architektur 
actual 


Abb. B-21: Erlaubte PORT MAP-Konstrukte in der Konfiguration 


Nicht erlaubt hingegen sind unbeschaltete "locals" und "formals", die 
mit mehr als einem "local" verknüpft werden. 


Folgende Alternative des Komplexgatters aus Kapitel 5 zeigt die An- 
wendung des Schlüsselwortes OPEN: 


CONFIGURATION aoi_config_4a OF aci IS 
FOR structural_4 
FOR nor_stage 
FOR or_c : or2 USE ENTITY work.or2 (behavioral); 
END FOR; 
END FOR; 
FOR and_stage 
hier:Verwendung eines AND3-Gatters in einem AND2-Sockel 
-- durch Angabe von OPEN als ACTUAL des dritten Eingangs- 
-- ports, work.and3 muss dort einen Defaultwert besitzen! 
FOR and_b : and2 USE ENTITY work.and3 (behavioral) 
PORT MAP (a = OPEN, b=> a, c=>b, y= y); 
END FOR; 
FOR and_a : and3 USE EN Y work.and3 (behavioral); 
END FOR; 
END FOR; 
END FOR; 


D acoi_config_4a; 


11.5 File - VO 


Files (Dateien) sind serielle Anordnungen von Daten eines bestimmten 
Typs, an deren Ende ein "end of file" (EOF)-Zeichen steht. Files wer- 
den nicht wie herkömmliche Objekte gelesen und zugewiesen, sondern 
können nur mit Hilfe spezieller Funktionen gehandhabt werden. Man 
unterscheidet bei VHDL zwischen Textfiles und typspezifischen Files. 
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Bei ersteren handelt es sich um beliebig strukturierte ASCII-Dateien, 
die mit Hilfe der Prozeduren aus dem Package textio gelesen und 
geschrieben werden können. Die typspezifischen Files dagegen kön- 
nen jeweils nur Daten eines Typs enthalten. Sie werden vom jeweiligen 
VHDL-Simulator mit den implizit vorhandenen Prozeduren read 
und write gelesen bzw. geschrieben. Dieser Dateityp ist nicht men- 
schenlesbar und kann nicht mit ASCII-Editoren erzeugt werden. 


Typdeklaration von Files 


Wie bei allen VHDL-Objekten ist zunächt eine Typdeklaration erfor- 
derlich, die den Namen des Filetyps mit dem Typ der Elemente ver- 
bindet: 


TYPE file_type_name IS FILE OF element_type ; 


Neben den Basistypen (bit, integer, ...) können auch benutzer- 
definierte Typen, Arrays und Records in einem File enthalten sein. 


Deklaration von Files 


Daraufhin kann nun ein konkretes Fileobjekt von diesem Typ dekla- 
riert werden. Dazu muß der Modus (IN: Leseoperation möglich, OUT: 
Schreiboperation möglich) und der Filename angegeben werden: 


FILE file_name : file_type_name IS IN 
"pohysical_file_name" 


FILE file_name : file_type_name IS OUT 
"pohysical_file_name" 


Durch den String "physical_file_name" wird der Dateiname 
im Filesystem angegeben, während file_name den Bezeichner des 
Objektes darstellt. Die Anwendung von Files in VHDL ist allerdings 
nicht sehr flexibel, da Files nur gelesen oder geschrieben werden 
können (es ist kein INOUT-Modus möglich) und auch die Reihenfol- 
ge streng sequentiell ist. 
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11.5.1 Typspezifische Files 


In diesem Fall werden Daten ein und desselben Typs in einem File ab- 
gespeichert oder gelesen, so z.B. integer, bit, bit_vector. Es 
stehen dafür folgende Leseprozeduren zur Verfügung: 


read (file_name, object_name) ; 
read (file_name, object_name, length) ; 


Beide Prozeduren lesen Daten aus dem File file_name in die Va- 
riable object_name. Handelt es sich beim einzulesenden Objekt 
um einen unbeschränkten Vektortyp (z.B.: bit_vector), so stellt 
die zweite Variante die Länge (length) des tatsächlich gelesenen 
Vektors zur Verfügung. 


Das Gegenstück zu read ist die Prozedur write, die den Inhalt von 
object_name auf das File file_name schreibt: 


write (file_name, object_name) ; 


Die folgende Funktion liefert eine Boolesche Variable, die entweder 
den Wert true für erreichtes Dateiende annimmt oder false ist, 
falls noch weitere Daten vorhanden sind. 


endfile (file_name) 


Folgendes Beispiel zeigt ein VHDL-Modell, das den Verlauf des Ein- 
gangssignals data_8 bis zum Zeitpunkt 100 ns auf die Datei 
data_8.out schreibt. Diese Datei könnte anschließend in einem 
anderen Modell mit der Prozedur read wieder eingelesen werden. 


PACKAGE memory_types IS 
SUBTYPE byte IS bit_vector (0 TO 7); 
END memory_types; 


USE work.memory_types.ALL; 
ENTITY write_data IS 

PORT (data_8 : IN byte); 
END write_data; 
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ARCHITECTURE behavioral OF write_data IS 
BEGIN 


write_process: PROCESS 


TYPE byte_file IS FILE OF byte; 
FILE output : byte_file IS OUT "data_8.out"; 
EGIN 
wWAIT on data_8; 
IF now <= 100 ns TH 
write (output, da 
ELSE 
WAIT; 
END IF; 
END PROCESS; 
D behavioral; 


11.5.2 Textfiles 


Eine Möglichkeit, innerhalb von Files auch unterschiedliche Typen 
abzuspeichern, bietet das Package textio aus der Bibliothek std. 
Es muß vor der Verwendung seiner Routinen erst mit folgender An- 
weisung bekanntgemacht werden: 


USE std.textio.ALL ; 


Das Package deklariert den Typ line und einen entsprechenden File- 
typ text. Files dieses Typs können mit folgenden Anweisungen zei- 
lenweise gelesen und geschrieben werden: 


readline (file_name, line_object_name) ; 
writeline (file_name, line_object_name) ; 
Mit Hilfe der überladenen Prozeduren aus dem Package textio: 
read (line_object_name, object_name) ; 
write (line_object_name, object_name) ; 


können verschiedene Objekttypen innerhalb der Zeilen gelesen und 
geschrieben werden. 


218 © G. Lehmann/B. Wunder/M. Selz 


11 Spezielle Modellierungstechniken 


Die möglichen Typen sind: 


71 bit 71 bit_vector 71 boolean 
71 time 71 integer 1 real 
1] character 71 string 


Für die Leseprozeduren existieren auch Varianten mit Booleschem 
Prüfwert zur Kontrolle auf erfolgreiche Datei-Operation. Für die 
Schreibprozeduren existieren Varianten zum Ausrichten der Objekte 
innerhalb eines gegebenen Bereiches. Weiterhin gibt es die Funktion: 


endline (line_object_name) 


zur Überprüfung auf erreichtes Zeilenende (vgl. endfile). 


Das prinzipielle Vorgehen beim Arbeiten mit Text-Files soll an einem 
Beispiel verdeutlicht werden. Es stellt eine flexible Testbench für ein 
beliebiges Modell mit drei Ein- und einem Ausgangsport dar. Die Zei- 
len im File "stimres" sind folgendermaßen aufgebaut: 


Signalname (Typ character) - Leerzeichen - Signalwert (Typ 
bit) - Leerzeichen - Zeitangabe der Zuweisung (Typ time): 


ao ı1ins 
b0O02ns 
r 14Ans 


Neben den Stimuli (Signale a,b, c) wird gleichzeitig die erwartete 
Antwort (Signal r) definiert und zu den entsprechenden Zeitpunkten 
mit dem Ausgangssignal y verglichen. Bei nicht übereinstimmenden 
Werten wird eine Fehlermeldung in das File "errors" geschrieben: 


USE std.textio.ALL; 


ENTITY tb_3pin IS 
END tb_3pin; 
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ARCHITECTURE arch_1 OF tb_3pin IS 
SIGNAL a,b,c,r,y: bit; 
COMPONENT mut_socket 
PORT (a,b,c: IN bit; y: OUT bit); 
END COMPONENT; 
FIL] 
FIL] 
EGIN 
model_under_test: mut_socket PORT MAP (a,b,c,y); 
read_stimuli: PROCI Lese Stimuli 
VARIABLE lin : line; VARIABLE boo: boolean; 
VARIABLE t : time; 
VARIABLE str_var,space: character; VARIABLE data: bit; 
EGIN 
WHILE (endfile (stimres) = false) LOOP 
readline (stimres, lin); 
read (lin,str_var,boo); 
ASSERT boo REPORT "Error reading file!"; 
IF ((str_var = 'a') OR (str_var = 'b') 
OR (str_var = 'c') OR (str_var = 'r')) TH 
read (lin,space); read (lin,data); 
read (lin,space); read (lin,t); 
str_var IS 
'a' => TRANSPORT 
YB! TRANSPORT 
TRANSPORT 
TRANSPORT 


stimres : text IS IN "stimres"; 
errors : text IS OUT "errors"; 


Di 
Di 


Ede 


END LOOP; 
WAIT; 
END PROCESS; 
write_errors : PROCI Schreibe Fehlermeldung 
VARIABLE lin : line; 
BEGIN 
wWAIT ON r'TRANSACTION; 
IF (y /= r) THEN 
write (lin, string' ("y isn't ")); write 
write (lin, string' (" at time ")); write 
writeline (errors, lin); 
END IF; 
END PROCESS; 
D arch_1; 
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11.5.3 Handhabung von Files in 93 


Die urspüngliche Definition der Syntax zur Handhabung von Files 
(/g7) enthält einige unklare Punkte und schränkt den Datenim- und 
-export von und zu Files erheblich ein. 


Die wesentlichen Neuerungen in 93 bezüglich Files sind: 


A Neben den Signalen, Variablen und Konstanten erhalten auch 
die Files explizit den Status einer eigenen Objektklasse. 


I Files Können als Argumente an Unterprogramme übergeben 
werden. 


I Files können durch Angabe eines Prozeduraufrufes explizit ge- 
öffnet oder geschlossen werden. Damit wird auch eine Abfrage 
auf Existenz der Datei möglich. 


m Files können neben "read" und "write" den Modus "append" an- 
nehmen. 


Mit diesen Neuerungen ist es, zusammen den "impure functions", nun 
möglich, mit Hilfe verschiedener Funktionen aus einem File zu lesen. 


11.6 Zeiger 


Wie in vielen Programmiersprachen kann auch in VHDL-Modellen 
mit Zeigern gearbeitet werden. Dadurch lassen sich sehr abstrakte, im- 
plementierungsunabhängige Modelle für elektronische Systeme erstel- 
len. Beispiele für die Anwendung von Zeigern sind dynamische Warte- 
schlangen oder Kellerspeicher. 


In VHDL sind Zeiger spezielle Variablen, die die Adresse für ein Ob- 
jekt speichern, das selbst nicht direkt ansprechbar ist, also keinen eige- 
nen Bezeichner (identifier) besitzt. Da Zeiger immer Variablen sind, 
können sie nur innerhalb von Prozessen oder Unterprogrammen ein- 
gesetzt werden. 


Typdeklaration von Zeigern 


Bevor eine Zeigervariable deklariert werden kann, ist die Deklaration 
des Zeigertyps (sog. "access-type") unter Angabe des Typs, auf den 
gezeigt werden soll (type_name), erforderlich: 
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TYPE pointer_type IS ACCESS type_name ; 


Deklaration von Zeigern 
Die Zeigervariable kann dann in drei Varianten deklariert werden: 


VARIABLE pointer_name : pointer_type 
:= NEW type_name ; 


VARIABLE pointer_name : pointer_type 
:= NEW type_name'(def_value) ; 


VARIABLE pointer_name : pointer_type 
:= NULL ; 


Bei der letzten Variante wird lediglich ein Zeiger angelegt, der auf 
kein Objekt zeigt. Die beiden anderen Varianten hingegen reservieren 
durch das Schlüsselwort NEW für ein Objekt vom Typ type_name 
den notwendigen Speicherplatz, legen dieses Objekt an und weisen 
ihm einen Defaultwert zu. Wird dieser Wert nicht wie in der zweiten 
Variante explizit angegeben, so entspricht der Defaultwert dem am 
weitesten links stehenden Wert in der Deklaration von type_name. 


Um den Speicherplatz eines Objektes wieder freizugeben, existiert die 
Prozedur deallocate, deren einziges Argument der entsprechende 
Zeigername ist: 


deallocate (pointer_name) ; 


Anwendung von Zeigern 


Folgendes Beispiel soll die Anwendung von Zeigern verdeutlichen: 


ENTITY acc_types IS 


END acc_types; 
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ECTURE behavioral OF acc_types IS 


ESS 

E pos2 IS ARRAY (1 DOWNTO 0) OF positive; 
E access_pos2 IS ACCESS pos2; 

VARIABLE pl : access_pos2 := NEW pos2!' (2,3); 
VARIABLE p2 : access_pos2 := NEW pos2; 
VARIABLE p3,p4 : access_pos2 := NULL; 


‚ALL := p2.ALL; 
deallocate (pl); 
WAIT; 

END PROCESS; 

END behavioral; 


In Zeile (2) wird ein Zeigertyp für den in Zeile (1) deklarierten 
Vektortyp deklariert. Die Zeilen (3) bis (5) deklarieren die vier Zei- 
gervariablen p1 bis p4. Zusätzlich wird in Zeile (3) und (4) jeweils 
ein nicht benanntes Objekt von Typ pos2 angelegt und initialisiert. 
Nach Abarbeitung dieser Zeilen, d.h. nach Ausführung der Prozeß- 
initialisierung, ergibt sich die in Abb. B-22 links dargestellte Situation. 


In den Zeilen (6) und (7) werden den Elementen des Objektes, auf 
das der Zeiger p2 zeigt, Werte zugewiesen. Das Schlüsselwort ALL be- 
wirkt ein sog. "Dereferenzieren" des Zeigers, d.h. daß nicht der Zeiger, 
sondern das Objekt, auf das gezeigt wird, angesprochen ist. Das 
Schlüsselwort ALL kann entfallen, wenn eine Bereichseinschränkung 
(wie in Zeile (7)) verwendet wird. 


In Zeile (8) wird dem Zeiger p3 die Adresse des Objektes überge- 
ben, auf das der Zeiger p2 zeigt. Zeile (9) bewirkt durch das Schlüs- 
selwort NEW eine Speicherplatzreservierung für ein Objekt. Die Adres- 
se dieses Objekts wird im Zeiger p4 gehalten. Sein initialer Wert wird 
durch die Zuweisung in Zeile (10) überschrieben. 


Mit der Prozedur deallocate () wirdin Zeile (11) der Speicher- 
bereich des Objekts freigegeben, auf das p1 gezeigt hat. 
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Nach Abarbeitung der Zeilen (6) bis (11) stellt sich die in Abb. B- 
22 rechts dargestellte Situation ein. 


pl P3 p4 
® 
le 
nach Prozeßinitialisierung nach Prozeßausführung 


Abb. B-22: Verwendung von Zeigern 


Unvollständige Typdeklaration 


Um mit VHDL auch rekursive Strukturen modellieren zu können, sind 
neben den Zeigern auch die sog. "incomplete types" notwendig. Wie 
der Name besagt, stellen diese eine unvollständige Typdeklaration dar: 


TYPE type_name ; 


Die zugehörige vollständige Typdeklaration muß innerhalb desselben 
Deklarationsbereiches nachfolgen. 


Anwendung von unvollständigen Typdeklarationen 


Die Anwendung einer unvollständigen Typdeklaration zur Model- 
lierung einer verketteten Liste wird am Beispiel einer Warteschlange 
gezeigt. Sie besteht aus beliebig vielen Elementen des Typs chain_ 
element, die aus dem eigentlichen Datenelement vom Typ inte- 
ger und einem Zeiger bestehen. Die Verkettung wird dadurch reali- 
siert, daß der Zeiger jedes Elementes auf das nächste Element zeigt. 


Zur Handhabung der Funktionalität sind zusätzlich zwei Zeiger 
(first und last) erforderlich, die auf das erste bzw. letzte Element 
der Warteschlange zeigen (Abb. B-23). 
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U)last 


next_element ( ) next_element (.) 


element_data element_data element_data 


next_element (0) 


Abb. B-23: Aufbau der Warteschlange 


Das VHDL-Modell zur Realisierung einer Warteschlange mit diesem 
Aufbau hat zwei Schnittstellen: Am Port command wird der Befehl 
für eine Operation auf der Warteschlange übergeben. Die Werte der 
Datenelemente werden über den Port value ausgegeben bzw. einge- 
lesen. 


ENTITY queue IS 
PORT (command : IN queue_access; 


value : INOUT integer); 
END queue; 


Die Alternativen für das Kommando sind im Typ queue_access 
deklariert: 
A nul: keine Aktion, 


I add_element: füge Element hinten (in Abb. B-23 rechts) 
an die Warteschlange an, wobei der aktuell anliegende Wert des 
Ports value abgespeichert wird, 


I delete_element: lösche das erste Element (ganz links) der 
Warteschlange nachdem dessen Wert am Port value ausgege- 
ben wurde. 


a read_element: lese das erste Element, ohne es zu löschen. 
Auch hier wird dessen Wert über den Port value bereitgestellt. 


© G. Lehmann/B. Wunder/M. Selz 225 


B Die Sprache VHDL 


ECTURE demo OF queue IS 
chain_element; -- unvollstaendige Dekl. 
pointer IS ACCESS chain_element; 
chain_element IS RECORD -- vollst. Deklaration 
next_element : pointer; 
element_data : integer; 
END RECORD; 
EGIN 
handle_queue : PROCESS (command) 
VARIABLE empty_flag : boolean := true; 
VARIABLE first, last, help : pointer := NULL; 
EGIN 
CASE command IS 
WHEN add_element => 
IF empty_flag THEN 
first := NEW chain_element; last := first; 
empty_flag := false; 
EILSE 
last.next_element := NEW chain_element; 
last := last.next_element; 
END IF; 
last.element_data := value; 
WHEN delete_element => 
IF empty_flag THEN 
ERT false REPORT "Empty queue!" SEVERITY note; 


ElLSE 
value <= first.element_data, 0 AFTER 10 ns; 
help := first; 
IF first = last THEN empty_flag := true; 

ELSE first := first.next_element; END IF; 

deallocate (help); 

D IF; 


EN read_element => 
IF empty_flag THEN 
ERT false REPORT "Empty queue!" SEVERITY note; 


ElSE 
value <= first.element_data, 0 AFTER 10 ns; 
END IF; 

WH] nul => NULL; 

END CASE; 

END PROCESS; 
D demo; 
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Das Beispiel zeigt, wie der Typ chain_element mit Hilfe der un- 
vollständigen Typdeklaration im Typ pointer bereits verwendet 
werden kann, bevor er vollständig deklariert wird. Gleichzeitig wird 
deutlich, wie ein Record und dessen Elemente durch seinen Zeiger mit 
Hilfe von "selected names" referenziert werden kann. 


Funktionsweise des Modells: 


Bei der Prozeßinitialisierung werden keine Speicherplätze für Elemen- 
te der Warteschlange allokiert. Dies geschieht erstmals durch das Kom- 
mando add_element. In diesem Fall wird der Zeiger first für 
das hinzuzufügende Element verwendet. Sind bereits Elemente vor- 
handen, wird das neue Element durch last..next_element refe- 
renziert. Der Zeiger last wird im Anschluß daran auf das jeweils 
letzte Element gesetzt. 


Das Löschen eines Elementes (delete_element) erfordert den 
temporären Zeiger help, der das später zu entfernende Element refe- 
renziert. Hier muß geprüft werden, ob es sich um das letzte Warte- 
schlangenelement handelt. Der Wert des zu löschenden Elementes wird 
an den Port value angelegt und der Zeiger first wird bei noch 
vorhandenen weiteren Elementen auf das nächste Element gesetzt. 


Das Kommando read_element gibt lediglich den Datenwert des 
ersten Elementes an den Ausgang weiter, ohne daß ein Element ge- 
löscht wird. 


11.7 Externe Unterprogramme und Architekturen 


VHDL bietet sehr viele Funktionen zur Handhabung von vordefinier- 
ten Typen. Für eigene Typen können Routinen selbst verfaßt werden. 
Trotzdem kann es zur Handhabung komplexer Operationen oder 
großer Datenmengen sinnvoll sein, die Fähigkeiten von höheren Pro- 
grammiersprachen zu nutzen. Prinzipiell ist es daher möglich, durch 
geeignete Schnittstellen externe Unterprogramme mit VHDL-Model- 
len zu verbinden. Eine weitere Anwendung von Schnittstellen wäre die 
Anbindung von fremden Architekturen oder gar von kompletten 
Modellen anderer Simulatoren. 
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Das LRM von Yg7 sieht zwar die Möglichkeit von Schnittstellen zu 
externen Funktionen über Packages vor, gibt aber über nähere Details 
keine Auskunft, d.h. es erlaubt die Verwendung, gibt aber keine Vor- 
gaben, wie die Schnittstelle aussehen muß, wie die externen Funktionen 
anzusprechen sind, usw. 


Die Situation hat sich heute dahingehend entwickelt, daß manche Soft- 
warefirmen simulatorspezifische, und damit uneinheitliche Schnittstel- 
len zu externen Funktionen (üblicherweise in "C") vorsehen, deren 
Handhabung aber alles andere als intuitiv ist. 


Mit Yg93 wird durch die Definition eines Attributes zumindest der Ver- 
such einer einheitlichen Handhabung unternommen. Die Definition 
der Schnittstelle (Signal-/Datentypen und -modi) bleibt aber weiterhin 
dem Softwarehersteller überlassen, ist also nach wie vor implementie- 
rungsabhängig. 


Im Package standard von 93 ist dazu das Attribut FOREIGN de- 
klariert, das als einziges vordefiniertes Attribut vom Benutzer zuge- 
wiesen werden kann: 


ATTRIBUTE FOREIGN : string; 


Externe Unterprogramme und Architekturen erhalten nun einheitlich 
einen VHDL-Rahmen und werden mit einem Attribut FOREIGN 
dekoriert. Dieses Attribut hat implementierungsabhängige Bedeutung 
und stellt die Verbindung zwischen dem VHDL-Bezeichner und dem 
Namen der externen Architektur bzw. des Unterprogramms her. Diese 
können dann wie herkömmliche Architekturen instantiiert oder wie 
normale Unterprogramme verwendet werden. Ein Beispiel: 


E ext OF anything IS 
E FOREIGN OF ext : ARCHIT E IS "lib_z2/a0i223"; 
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1.1 Überblick 


Die Simulation dient im allgemeinen der Verifikation von Entwurfs- 
schritten. Bei einer Designmethodik mit VHDL unter Verwendung von 
Synthesewerkzeugen werden vorwiegend Verhaltensmodelle auf ab- 
strakten Entwurfsebenen (System-, Algorithmische und Register- 
Transfer-Ebene) und die entsprechenden strukturalen Modelle auf Lo- 
gikebene eingesetzt. Die Simulation von VHDL-Modellen hat dabei 
konkret folgende Aufgaben zu erfüllen: 


1.1.1 Simulation von Verhaltensmodellen 


In der Regel werden Verhaltensmodelle von Hand erstellt oder durch 
ein Front-End-Tool generiert. Verhaltensmodelle dienen 


A zur frühzeitigen Verifikation des Entwurfs, 


I als Eingabe für ein Synthesewerkzeug. 


Meist wird für das Verhaltensmodell bereits auf abstrakter Ebene eine 
Testumgebung ("Testbench") des Modells erstellt, welche die Ein- 
gangssignale (Stimuli) für das Modell zur Verfügung stellt und dessen 
Ausgangssignale (Ist-Antworten) mit den erwarteten Werten (Soll- 
Antworten) vergleicht. Durch die Angabe von erwarteten Antworten 
kann ein aufwendiges und fehlerträchtiges, manuelles Überprüfen der 
Ausgangssignale entfallen. 


Eine Simulation von Verhaltensmodellen auf abstraktem Niveau muß 
folgende Fragen beantworten: 


Ist das Modell syntaktisch korrekt? 


Manuell erstellte VHDL-Modelle sind in der Regel nicht von vorne 
herein syntaktisch korrekt. Eine entsprechende Überprüfung kann 
vom Compiler-Modul des VHDL-Simulators oder von speziellen Syn- 
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tax-Checkern durchgeführt werden. Wurde das Verhaltensmodell 
durch ein Front-End-Tool generiert, kann man von der syntaktischen 
Korrektheit des Modells ausgehen. 


Stimmt das Modell mit der Spezifikation überein? 


Die Überprüfung der funktionalen Korrektheit des Entwurfsschrittes 
von der Spezifikation zum abstrakten Verhaltensmodell ist der eigent- 
liche Sinn einer Simulation. Dabei stellt sich das Problem, daß durch 
die Simulation zwar die Anwesenheit eines Fehlers gezeigt, für größere 
Schaltungen aber nie die Abwesenheit von Fehlern bewiesen werden 
kann. Es existieren zur Verifikation des funktionalen Verhaltens zwar 
andere Verfahren, die dies leisten (formale Verifikation), ausgereifte 
Werkzeuge zur Handhabung komplexer Schaltungen stehen aber da- 
für nicht zur Verfügung. 


Welche Eigenschaften besitzt das modellierte System? 


Neben einer Überprüfung der Funktionalität kann durch die Simula- 
tion des Verhaltensmodells beispielsweise die Auslastung von Bussen 
oder eine geeignete Synchronisation von Submodulen bestimmt wer- 
den. 


1.1.2 Simulation von strukturalen Modellen 


Die VHDL-Gatternetzlisten werden kaum manuell erstellt. Sie werden 
in der Regel, unter Verwendung von technologiespezifischen Logik- 
modellen, mit Hilfe von Synthesewerkzeugen generiert. Die Simula- 
tion solcher Modelle dient zur Untersuchung der Frage: 


Stimmt die Gatternetzliste mit dem Verhaltensmodell funktional 
überein und erfüllt sie die zeitlichen Anforderungen? 


Bei einer Simulation der Gatternetzliste werden nicht nur funktionale 
Aspekte, sondern auch die zeitlichen Randbedingungen untersucht. 
Dazu kann die Testbench des Verhaltensmodells, ggf. nach Hinzufü- 
gen von weiteren zeitlichen Informationen oder genauerer Überprü- 
fung der Ausgänge, verwendet werden. Sollen auch die Einflüsse des 
Layouts auf das zeitliche Verhalten der Gatternetzliste untersucht wer- 
den, so muß ein Backannotation-Schritt erfolgen, d.h. Informationen 
aus dem Layout - dabei handelt es sich typischerweise um die Ein- 
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flüsse der Leitungskapazitäten - werden in das Logikmodell zurückge- 
führt. 


1.2 Simulationstechniken 


Eine Kenntnis der unterschiedlichen Simulationstechniken ist u.a. für 
die Auswahl eines geeigneten Simulators bei gegebenen Schaltungs- 
größen wichtig, denn sie beeinflussen die Performance des Simulators 
erheblich. Prinzipiell unterscheidet man, ähnlich wie bei Interpretern 
und Compilern für Programmiersprachen, zwei Konzepte für VHDL- 
Simulatoren, das interpretierende und das compilierende. 


1.2.1 Interpretierende Simulationstechnik 


Sie kann als die klassische Methode angesehen werden. Der VHDL- 
Quellcode wird bei der Simulationsvorbereitung in einen Pseudo-Code 
umgewandelt, der mit einem, meist auf der Programmiersprache "C" 
basierenden Simulator abgearbeitet werden kann. Kennzeichen der 
interpretierenden Simulationstechnik sind kurze Zeiten bei der Simu- 
lationsvorbereitung und längere Zeiten bei der Simulation selbst. 


1.2.2 Compilierende Simulationstechnik 


Hierbei wird der VHDL-Quellcode bei der Simulationsvorbereitung 
zunächst komplett in "C" übersetzt und mit einem C-Compiler in 
Objektcode umgewandelt. Bei der eigentlichen Simulation kann also 
direkt ein Maschinenprogramm ausgeführt werden. Längere Zeiten 
bei der Simulationsvorbereitung stehen einem schnelleren Simula- 
tionsablauf gegenüber. 


Normalerweise ist die interpretierende Technik eher für kleinere Mo- 
delle geeignet, bei denen die Simulationszeit nicht sehr ins Gewicht 
fällt. Bei großen Modellen und langen Simulationszeiten macht sich 
jedoch aufgrund einer schnelleren Simulation der Vorteil einer compi- 
lierenden Technik bemerkbar. 


232 © G. Lehmann/B. Wunder/M. Selz 


1 Simulation 


1.2.3 Native-Compiled Simulationstechnik 


Neuartige Simulatoren gehen einen Zwischenweg und versuchen, die 
Vorteile beider Ansätze zu verknüpfen. Bei der Methode der Native- 
Compiled-Simulation entfällt die Übersetzung in "C"; statt dessen wird 
aus dem VHDL-Quellcode direkt der Maschinencode erzeugt. Da- 
durch wird einerseits die Simulationsvorbereitungszeit im Bereich ei- 
nes interpretierenden Simulators liegen, während andererseits ein aus- 
gesprochen optimierter Objektcode vorliegt. Die eigentliche Simu- 
lation sollte noch deutlich schneller als bei compilierenden Simula- 
toren ablaufen. 


Abb. C-1 stellt die drei Simulationstechniken gegenüber. 


compilierend interpretierend native-compiled 
VHDL-Code VHDL-Code VHDL-Code 
Parser, Parser, Parser, 
C-Code-Gen. P-Code-Gen. Obj.-Code-Gen. 


generischer 
Object-Code 


C-Compiler Linker 


und Linker Linker (Runtime Library) 
Object-Code P-Code Stream Object-Code 
Abb. C-1: Simulationstechniken 
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1.3 _Simulationsphasen 


Gemäß dem LRM! der Sprache VHDL erfolgt die Simulation einer 
VHDL-Beschreibung in den drei Schritten "Elaboration", "Initializa- 
tion" und "Execution". 


In der "Elaboration''-Phase wird das Netzwerk der Schaltung mit allen 
Hierarchieebenen, Blöcken und Signalen aus den compilierten VHDL- 
Modellen aufgebaut. Die Elaboration-Phase ist vergleichbar mit dem 
"Link"-Vorgang bei der Software-Entwicklung. 


In der "Initialization''-Phase werden alle Signale, Variablen und Kon- 
stanten mit Anfangswerten versehen. Anfangswert ist entweder der 
Wert, der in der VHDL-Beschreibung durch explizite Angabe bei der 
Deklaration des Objektes vorgegeben wurde oder der Wert, der durch 
das LEFT-Attribut des entsprechenden Typs spezifiziert ist. Außerdem 
wird in dieser Phase jeder Prozeß einmal gestartet und bis zur ersten 
WAIT-Anweisung bzw. bis zum Ende ausgeführt. 


In der "Execution'-Phase wird die eigentliche Simulation durchge- 
führt. Zu jedem Zeitpunkt der Simulation erfolgen bis zum Eintreten 
eines stabilen Zustandes ein oder mehrere Delta-Zyklen. Anschließend 
wird die Simulationszeit bis zum nächsten Eintrag in der Ereignisliste 
erhöht. Die Simulation ist beendet, wenn eine spezifizierte Simula- 
tionsdauer erreicht ist oder wenn keine weiteren Signaländerungen 
mehr auftreten. 


1.4  Testumgebungen 


Zu einer kompletten Beschreibung eines elektronischen Systems in 
VHDL gehört auch eine Testumgebung (im Englischen "Testbench"). 
Darunter versteht man die Bereitstellung von Eingangssignalen (Sti- 
muli) und die Überprüfung der Ausgangssignale (Ist-Antworten) mit 
den erwarteten Werten (Soll-Antworten). Testumgebungen können 


1 LRM = Language Reference Manual 
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auch dazu verwendet werden, verschiedene Architekturen einer Entity 
miteinander zu vergleichen: ein Verhaltensmodell auf RT-Ebene kann 
z.B. mit dessen Syntheseergebnis (Gatternetzliste) verglichen werden. 


Für die Bereitstellung der Stimuli und der Soll-Antworten sowie für 
die Instantiierung des zu testenden Modells ("model under test", MUT) 
sind verschiedene Strategien denkbar. 


Die kompakteste Möglichkeit besteht darin, in der Testbench selbst 
Stimuli zu beschreiben und die Antworten des Modells zu überprüfen. 
Dies kann z.B. in getrennten Prozessen erfolgen. In dieser Testbench 
wird gleichzeitig auch das MUT instantiiert und mit den Stimuli bzw. 
Antwortsignalen verdrahtet (siehe Abb. C-2). 


stimuli response 


generation za Ze control 


model model_tb 


Abb. C-2: Testbenchstrategie mit einem VHDL-Modell 


Daneben können Stimulibeschreibung und Antwortkontrolle auch in 
einem oder zwei unabhängigen VHDL-Modellen erfolgen (siehe Abb. 
C-3). Die Testbench dient in diesem Fall nur der Zusammenschaltung 
der zwei bzw. drei Modelle. Sie ist also rein struktural. 


Eine Testbenchstrategie, die auf mehreren Modellen basiert, ist auf- 
wendiger zu erstellen, als eine aus einem einzigen Modell bestehende 
Testbench. Allerdings bietet eine feinere Strukturierung den Vorteil, 
daß sich die einzelnen Modelle leichter in anderen Entwürfen wieder- 
verwenden lassen und die Stimuli-Datensätze einfacher ausgewechselt 
werden können. 
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stimuli response 
generation control 


model_stim model model_tb 


stimuli response 
generation control 


model_stim model_resp 
model model_tb 
Abb. C-3: Testbenchstrategie mit zwei oder drei VHDL-Modellen 


Bei der Beschreibung der Stimuli selbst bietet sich eine kombinierte 
Zuweisung von mehreren Signalen in einer Signalzuweisung an. Dazu 
ist i.d.R. ein qualifizierter Ausdruck erforderlich. 


Folgendes Beispiel beschreibt die Stimuli für ein NAND2-Modell und 
überprüft die Antworten jeweils 2 ns danach. Die Testbench ist nach 
der erstgenannten Strategie angelegt. 


ENTITY nand2_tb IS -- Testbench-Entity 
END nand2_tb; -- ohne Ports 
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HITECTURE strategy_l OF nand2_tb IS 
COMPONENT nand2_socket 

PORT (int, In2 = IN biE > outl-% QUT’bit); 
END COMPONENT; 
SIGNAL a,b,c : kit; 
SUBTYPE t2 IS bit_vector (1 TO 2); 


tantiierung des Model under Test (mut) 
mut : nand2_socket PORT MAP (a,b,c); 
Beschreibung der Eingangssignale (Stimuli) 
timuli_generation: PROCESS 
EGIN 

-- eine Zuweisung zum Zeitpunkt 0 

(a, b) <= t2' ("01") AFTER 10 ns, qualifizierter 
t2'("10") AFTER 20 ns, Ausdruck t2'(... 


) 
t2' ("11") AFTER 30 ns, 
) 


t2'("00") AFTER 40 ns; 


WAIT; 
END PROCESS; 
Ueberpruefung der Modellantworten sponses) 
response_control : PROCESS 
BEGIN 
wAIT FOR 12 ns; -- absolut: 12 ns 
ASSERT c='1' REPO "wrong result" SEVERITY note; 
wAIT FOR 10 ns; -- absolut: 22 ns 
ASSERT c='1' REPO "wrong result" SEVERITY note; 
wAIT FOR 10 ns; -- absolut: 32 ns 
ASSERT c='0' REPO "wrong result" SEVERITY note; 
wAIT FOR 10 ns; -- absolut: 42 ns 
ASS] c='1' REPO "wrong result" SEVERITY note; 
WAIT; 
END PROCESS; 
END strategy_1; 


Die Signalzuweisung der Stimuli erfolgt im ersten Prozeß Komplett 
zum Zeitnullpunkt. Sie könnte alternativ auch als nebenläufige Anwei- 
sung erfolgen. Die Assertions im zweiten Prozeß hingegen müssen, 
durch WAIT-Anweisungen gesteuert, zum entsprechenden Zeitpunkt 
ausgeführt werden. 


Werden bei der Stimulibeschreibung mehrere Einzelanweisungen ver- 
wendet, so ist das "Transport"-Verzögerungsmodell einzusetzen, da 
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sonst durch das "Inertial"-Verzögerungsmodell die vorhergehenden 
Signalwechsel wieder gelöscht werden: 


single_step_stimuli_generation : P 
BEGIN 
4 Zuweisungen zum Zeitpunkt 
<= TRANSPORT t2' ("01") 
TRANSPORT 
TRANSPORT 
TRANSPORT 


END PROC 


Es können alternativ dazu die Stimuli auch zu den entsprechenden 
Zeiten erzeugt werden. Dies ist mit WAIT-Anweisungen zu steuern. 
Denkbar wäre in diesem Fall auch eine Kombination mit der Antwort- 
kontrolle: 


multiple_step_stimuli_generation : PROC 
BEGIN 4 Zuweisungen zu verschiedenen Zeitpunkten 
WAIT FOR 10 ns; (a, b) <= t2' ("01"); -- absolut 
WAIT FOR 10 b) <= t2' ("10"); -- absolut 
WAIT FOR 10 5 by) Ze Eat "110, -- absolut 
WAIT FOR 10 s b) <= t2' ("00"); -- absolut 
WAIT; 
END PROCESS; 


timuli_generation_and_response_control : PROC 
EGIN 
wAIT FOR 10 ns; (a, b) <= t2' ("O1"); -- absolu 
wAIT FOR 2 ns; -- absolu 
ASSERT c='1' REPORT "wrong result" SEVERITY note; 
wWAIT FOR 8.ns; (a, b) <= t2'("10"); -- absolu 
wAIT FOR 2 ns; -- absolu 
ASSERT c='1' REPORT "wrong result" SEVERITY note; 
wWAIT FOR 8.ns; (a, b) <= t2' ("11"); -- absolu 
wAIT FOR 2 ns; absolu 
ASSERT c='0' REPORT "wrong resul 
Fortsetzung auf naechster Sei 
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Fortsetzung von vorhergehender Seit 
WAIT FOR 8ns; (a, b) <= t2' ("00"); -- absolut 40 ns 


wWAIT FOR 2ns; -- absolut 42 ns 


ASSERT c='1' REPORT "wrong result" SEVERITY note; 
WAIT; 
END PROCESS; 


Zur Beschreibung regelmäßiger oder komplexer Stimuli eignen sich 
die sequentiellen Konstrukte der Sprache VHDL. Es sei hier auf eine 
der Übungsaufgaben in Teil D zur Erzeugung eines Taktsignals ver- 
wiesen. Die Stimuli für einen 8-Bit Decoder können etwa auf folgende 
Art beschrieben werden: 


ENTITY dec_stim IS 
PORT (stim : OUT bit_vector (7 DOWNTO 0)); 
END dec_stim; 


ARCHITECTURE behavioral OF dec_stim IS 
-- Funktion zur Wandlung einer Integerzahl in e. Bit-Vektor 
FUNCTION integer_to_bit (a: integer) RETURN bit_vector IS 


END integer_to_bit; 
BEGIN 
-- Zyklische Ausgabe von 0 bis 255 
stimuli_generation: PROCESS 
VARIABLE a : integer := 0; 
BEGIN 
WAIT FOR 10 ns; -- Stimulifrequenz: 100 MHz 
stim <= integer_to_bit (a); 
a:=at]; 
IF a > 255 TH 
END PROCESS; 


END behavioral; 
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1.5 Simulation von VHDL-Gatternetzlisten 


Beim Einsatz von VHDL zur Dokumentation und Simulation von 
elektronischen Schaltungen beschränkt man sich hauptsächlich auf ab- 
strakte Beschreibungsebenen. Typischerweise wird VHDL auf System- 
ebene, Algorithmischer Ebene und auf der Register-Transfer-Ebene 
als Eingabeformat für Syntheseprogramme eingesetzt. Bei der Verifi- 
kation der generierten Netzliste hingegen setzt man oft noch auf spe- 
zielle Digitalsimulatoren. Da VHDL leistungsfähige Konzepte zum 
Vergleich von Beschreibungen auf RT-Ebene und Logikebene anbie- 
tet (Auflösungsfunktionen, Assertions), drängt sich ein Einsatz auch 
auf dieser Ebene auf. Dies wird momentan jedoch durch zwei Pro- 
bleme erschwert: 


1.5.1 Performance-Nachteile 


VHDL-Simulatoren arbeiten auf der Logikebene heute noch wesent- 
lich langsamer als reine Digitalsimulatoren, die speziell für diesen 
Zweck entwickelt wurden. Führende Softwarehersteller haben jedoch 
angekündigt, daß die Leistung ihrer VHDL-Simulatoren entweder bald 
(d.h. bis Mitte 1994) die Leistung der konventionellen Digitalsimula- 
toren erreichen werde oder daß sie ihren VHDL-Simulator mit dem 
Digitalsimulator verschmelzen wollen. 


1.5.2 Verfügbarkeit von Technologiebibliotheken 


Zur Zeit sind kaum verifizierte VHDL-Gattermodelle in technologie- 
spezifischen Bibliotheken verfügbar. 


Einen Lösungsansatz zur Beseitigung dieses Engpasses könnte die 
Initiative VITALI! darstellen. Sie dient dem Zweck, ASIC-Bibliotheken 
für VHDL schneller verfügbar zu machen. Der Grundstein hierfür 
wurde 1992 beim "VHDL International Users Forum" (VIUF) und auf 
der "Design Automation Conference" (DAC) gelegt. Im Oktober 1992 


I VITAL = VHDL Initiative Towards ASIC Libraries 
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wurde bereits eine technische Spezifikation vorgelegt. VITAL umfaßt 
eine Beschreibungsform für das Zeitverhalten in ASIC-Modellen 
durch ein spezielles Format, SDF ("standard delay format"), und er- 
möglicht den Zugriff auf Standardbibliotheken der Hersteller. 


VITAL erfreut sich einer starken Unterstützung durch CAE- und 
ASIC-Hersteller. Die Softwarehersteller wollen unmittelbar nach Fest- 
legung des technologieunabhängigen Standards ihre Werkzeuge an- 
passen. Falls zu diesem Zeitpunkt auch leistungsfähigere Simulatoren 
zur Verfügung stehen, dürfte die VHDL-Simulation auf Logikebene 
keine Nachteile gegenüber der Simulation mit speziellen Digitalsimu- 
latoren mehr aufweisen. 
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2.1 Synthesearten 


Unter Synthese versteht man allgemein den Übergang von der forma- 
len Beschreibung eines Verhaltens zu einer dieses Verhalten realisie- 
renden Struktur. Abhängig vom Abstraktionsgrad der Beschreibung, 
die als Eingabe für die Synthese dient, spricht man von Logiksynthese, 
Register-Transfer-Synthese, Algorithmischer Synthese und Systemsyn- 
these. Während die Systemsynthese gegenwärtig noch vom Entwickler 
von Hand durchzuführen ist, stehen für die übrigen Synthesearten be- 
reits Programme zur Verfügung. Die meisten beschränken sich dabei 
jedoch auf die Register-Transfer-Ebene oder Logikebene. 


2.1.1 Systemsynthese 


Auf der Systemebene wird ein Modul global durch seine Leistung und 
Funktion beschrieben. Die Systemsynthese entwickelt aus einer forma- 
len Spezifikation einzelne Teilprozesse und entscheidet aufgrund der 
Vorgaben über einen günstigen Parallelitätsgrad in der Abarbeitung 
der Prozesse. Es ergibt sich eine Grobstruktur aus mehreren Subsy- 
stemen. 


2.1.2 Algorithmische Synthese 


Die Algorithmische Synthese transformiert ein Verhaltensmodell in 
eine Struktur auf Register-Transfer-Ebene. Das Verhaltensmodell ent- 
hält dabei lediglich den Algorithmus, der die Eingabedaten in Ausga- 
bedaten überführt. Die Darstellung erfolgt mittels einer Hardwarebe- 
schreibung, die Sequenzen, Iterationen und Verzweigungen enthält. 


Auf der resultierenden Register-Transfer-Ebene wird die Schaltung 
durch eine Struktur aus Registern, Funktionseinheiten (z.B. Addierer, 
Multiplizierer, Komparatoren, etc.), Multiplexern und Verbindungs- 
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strukturen beschrieben. Zur Ansteuerung der Hardwaremodule wird 
die Zustandsübergangstabelle eines endlichen Zustandsautomaten 
(FSM = Finite State Machine) generiert. 


Grundprinzip der algorithmischen Synthese ist meistens die Umset- 
zung der algorithmischen Beschreibung in einen Datenfluß- und einen 
Kontrollflußgraphen (Abb. C-4). 


Algorithmische 
Beschreibung 


Compilierung 
Datenflußgraph 
Datenpfadsynthese 


| Transformation | 
Ba Scheduling 


Kontrollpfadsynthese 


Zustandsreduktion 
Zustandscodierung 


Kontrollflußgraph 


| 


Beschreibung auf 
RT-Ebene 


Abb. C-4: Ablauf der Algorithmischen Synthese [BIT 92] 


Mit dem Datenflußgraphen werden die einzelnen Operationen, die die 
Eingangssignale in Ausgangssignale überführen, beschrieben. Die 
Knoten des Datenflußgraphen repräsentieren die verschiedenen Opera- 
tionen; Kanten geben Variablen oder Konstanten wieder und definie- 
ren die Abhängigkeiten der Operatoren. Der Graph muß nicht zusam- 
menhängend sein, parallele Abläufe sind möglich. Der zeitliche Ab- 
lauf der einzelnen Operationen wird dagegen im Kontrollflußgraphen 
abgebildet. Die Knoten dieses Graphen sind die Zustände des endli- 
chen Automaten, die Kanten die Zustandsübergänge. 


Die Synthese des Datenpfades besteht in der Realisierung des spezifi- 
zierten Algorithmus mit einer geeigneten Auswahl und Anzahl von 
Hardwaremodulen (z.B. Addierer, Register, Speicher sowie Multiplexer 
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und Busse zur Verbindung der Funktionseinheiten). Zur Ansteuerung 
dieser Module generiert die Kontrollpfadsynthese einen endlichen Au- 
tomaten, der die Datenpfadregister lädt, Multiplexer und Busse schaltet 
und die auszuführenden Operationen auswählt. 


2.1.3 Register-Transfer-Synthese 


Auf Register-Transfer-Ebene wird der Datenfluß einer Schaltung dar- 
gestellt. Die Beschreibung enthält neben Funktions- auch Strukturan- 
gaben des Entwurfs. Die dabei verwendeten Signale und Zuweisungen 
an Signale können nahezu direkt in eine Struktur aus Registern und 
Verarbeitungseinheiten ("Transfers") zwischen den Registern übertra- 
gen werden. 


Während auf Algorithmischer Ebene eine Schaltung aus imperativer 
Sicht, d.h. der Sicht des Steuerwerks, beschrieben wird, das die einzel- 
nen Aktionen sequentiell zu vorhergehenden Aktionen anstößt, wird 
das Verhalten auf RT-Ebene aus der reaktiven Sicht der Elemente 
dargestellt. Das bedeutet, daß die einzelnen Objekte "beobachten", ob 
eine bestimmte Triggerbedingung wahr wird, und dann entsprechende 
Aktionen ausführen. 


Die einzelnen Komponenten der Register-Transfer-Ebene sind keiner 
Ordnung unterworfen. Als typische Sprachelemente zur Definition der 
Objekte dienen sog. "guarded commands". Sie repräsentieren Verar- 
beitungen, die dann aktiviert werden, wenn bestimmte Ereignisse ein- 
treten. Die Register-Transfer-Ebene enthält außerdem ein bestimmtes 
Synchronisationsschema, das durch die Triggerbedingungen definiert 
ist. 


Ein Beispiel: 


Ausgegangen wird von einer Schaltung, die unter anderem zwei 
Register enthält, welche bidirektional mit zwei Bussen verbun- 
den sind. Auf einer ALU können Additionen, Subtraktionen 
und UND-Verknüpfungen durchgeführt werden. Das Opera- 
tionsergebnis wird in einem dritten Register gespeichert, welches 
auf die beiden Busse schreiben kann. Die steigende Flanke des 
Taktes triggert die Operatoren und Register. 
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Die Register-Transfer-Synthese setzt das Verhaltensmodell eins-zu- 
eins in eine äquivalente Blockstruktur auf gleicher Ebene um. Ähnlich 
der algorithmischen Synthese werden Kontroll- und Datenpfad ge- 
trennt behandelt. 


Bei der Datenpfadsynthese wird zunächst festgestellt, welche Signale 
gespeichert werden müssen. Dafür werden Flip-Flops bzw. Register 
angelegt. Die Art der Flip-Flops (D-Flip-Flop, J-K-Flip-Flop, getrig- 
gert durch steigende oder fallende Flanke, etc.) gibt die Triggerbe- 
dingung und Blockbeschreibung vor. Für die Verarbeitung der nicht 
zu speichernden Signale werden nur kombinatorische Logik und 
Verbindungsleitungen vorgesehen. 


Durch Analyse der Signalabhängigkeiten können die Verbindungs- 
strukturen ermittelt werden. Diese bestehen aus dedizierten Leitungen 
und Bussen sowie aus Treibern und Multiplexern zwischen den Regi- 
stern und zwischen Registern und Operationseinheiten. 


Die Kontrollpfadsynthese erzeugt die Steuerung der Register-Trans- 
fers aus den Triggerbedingungen. Wie in der Algorithmischen Synthe- 
se wird dazu ein Automat angelegt, um Treiber und Multiplexer anzu- 
steuern. Das Übergangsnetzwerk des Automaten, das durch Boolesche 
Gleichungen repräsentiert wird, kann mit der anschließenden Logik- 
synthese implementiert werden. 


Aus den Ergebnissen der Daten- und Kontrollpfadsynthese wird meist 
eine generische Netzliste aus den Elementen einer technologieunab- 
hängigen Bibliothek erzeugt. In dieser Bibliothek sind die Gatter- 
strukturen der einzelnen Elemente hinterlegt. Die Abbildung der Gat- 
ter auf eine technologiespezifische Bibliothek geschieht im Techno- 
logy Mapping der Logiksynthese. 


2.1.4 Logiksynthese 


Bei der Logiksynthese werden die realisierungsunabhängigen Boole- 
schen Beschreibungen der kombinatorischen Netzwerke (Multiplexer, 
Operatoren, Übergangsnetzwerke der Automaten, etc.) optimiert und 
anschließend mit den Elementen der gewählten Zieltechnologie aufge- 
baut. Diese technologiespezifische Netzliste wird wiederum optimiert, 
um die Benutzervorgaben zu erreichen. 
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Folgende Einzelschritte laufen bei der Logiksynthese mit kommerziel- 
len Werkzeugen im allgemeinen ab: 


Flattening 


Alle Zwischenvariablen der Booleschen Ausdrücke werden zunächst 
entfernt und alle Klammern aufgelöst. Damit erhält man beispielsweise 
eine zweistufige AND-OR-INVERT-Darstellung: 


I Vor dem Flattening: 
f= flAaß; mit fl=av(er(cvd)); R2=cvb 


I Nach dem Flattening: 
f= (arc)v(arnb)v(cere)v(erndrc)v(ercrb)v 
(eadıib) 


Das Flattening löst also die vorgegebene Struktur der Logik auf. Die 
Auflösung eines vorher strukturierten Blockes in seine Produktterme 
kann eventuell bzgl. Geschwindigkeit und Fläche schlechtere Ergeb- 
nisse liefern. Bei unstrukturierter, krauser Logik ist es aber möglich, 
durch die anschließende Minimierung sowohl schnellere als auch klei- 
nere Schaltungen zu erzeugen. Weil durch das Auflösen der 
Zwischenterme große Datenmengen entstehen, kann in den meisten 
Synthesesystemen der Grad des Flattenings vorgegeben werden. 


Logikminimierung 


Die Darstellung aus Produkttermen wird mit Minimierungsverfahren, 
wie z.B. dem Nelson-Verfahren, weiterverarbeitet. Jede Funktion kann 
dabei einzeln oder innerhalb eines Funktionsbündels minimiert wer- 
den. Die Anzahl der Produktterme reduziert sich dadurch und redun- 
dante Logik wird entfernt. 


Structuring 


Beim Structuring oder Factoring werden gemeinsame Unterausdrücke 
ausgeklammert und als temporäre Variablen verwendet. Die Schaltung 
erhält erneut eine Struktur. Dabei wird zunächst ein Liste angelegt, die 
die möglichen Faktoren enthält. Die Bewertung der Faktoren (benötig- 
te Halbleiterfläche, Anzahl ihrer Verwendung) wird so oft wiederholt, 
bis kein neuer Faktor ermittelt werden kann, der die Schaltung verbes- 
sert. Die Faktoren, die die Logik am stärksten reduzieren, werden zu 
temporären Variablen. Ein Beispiel zum Structuring: 
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I Vor dem Structuring: 
f = (arad)v(are)v(bacrd)v(bAacnre) 


I Nach dem Structuring: 
f= t@Atl; mit: {}W=avc(baAc) tl=dve 


Auswirkungen der Optimierungen 


Die richtige Anwendung der verwendeten Strategien beim Einsatz ei- 
nes Synthesewerkzeuges hat entscheidenden Einfluß auf das Syn- 
theseergebnis. Spaltet man ein Design durch Flattening vollständig in 
Produktterme auf, minimiert anschließend die einzelnen Funktionen 
getrennt und verzichtet auf Structuring, so erhält man eine große, aber 
sehr schnelle Schaltung, da nur wenige Logikstufen zwischen den Ein- 
und Ausgängen liegen. Wird die ursprüngliche Struktur allerdings 
beibehalten und zusätzlich das Structuring verwendet, so kann eine 
kleine, aber langsame Schaltung entstehen. 


Die Strategie, mit der eine Schaltung optimiert werden kann, hängt von 
verschiedenen Faktoren ab, wie ihre Komplexität, die Anzahl der Ein- 
und Ausgänge oder die Güte der vorgegebenen Struktur. Dadurch 
bietet es sich an, mit Synthesewerkzeugen verschiedene Möglichkeiten 
auszuprobieren. 


Technology Mapping 


Vor dem Technology Mapping ist die synthetisierte Schaltung noch 
technologieunabhängig. Das Technology Mapping setzt die optimierte 
Logik und die Flip-Flops in die Gatter einer bestimmten Technologie- 
bibliothek um. 


Zunächst wird die Schaltung vollständig mit technologiespezifischen 
Gattern abgebildet. Durch lokales Neuarrangieren von Komponenten 
oder Verwendung von Bausteinen mit unterschiedlicher Anzahl an 
Eingängen wird versucht, die "constraints" des Entwicklers zu erfüllen. 
Die benutzerdefinierten Einschränkungen beziehen sich neben einer 
maximal zulässigen Fläche, maximaler Laufzeit oder Taktrate auch auf 
die Setup- und Hold-Zeiten für die Flip-Flops. Für diese Parameter 
wird eine Kostenfunktion erstellt, die durch geeignete Partitionierung 
und lokale Substitutionen von Gatterkonfigurationen minimiert wird. 
Hierbei werden heuristische Techniken angewandt. 
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Ein wichtiges Leistungsmerkmal eines Mapping-Algorithmus ist seine 
universelle Anwendbarkeit auf verschiedene Technologiebibliotheken, 
die sehr unterschiedliche Komplexgatter und Makrofunktionen ent- 
halten können. Ein Problem ist die schnelle Zunahme an benötigter 
Rechenzeit bei großen Schaltungen mit vielen Gattern. 


Abb. C-5 zeigt zwei Beispiele zum Technology Mapping. Beispiels- 
weise muß bei diesem Vorgang eine logische Verknüpfung mit vier 
Eingangsvariablen durch eine funktional äquivalente Verknüpfung 
aus drei Gattern mit jeweils zwei Eingangsvariablen ersetzt werden, da 
nur diese in der Technologiebibliothek verfügbar sind (oberes Bei- 
spiel). Eine Einsparung von Gattern beim Mapping ist unter anderem 
möglich, wenn in der Bibliothek Module mit negierten Ausgängen 
vorliegen (unteres Beispiel). 


1blıo a y 1D Q 
c1 ® cı a y 
Abb. C-5: Beispiele zum Technology Mapping 


Auch manuell erstellte Netzlisten können mit den Logiksynthese- 
Werkzeugen optimiert oder von einer Technologiebibliothek auf eine 
andere umgesetzt werden. Das Ergebnis der Synthese kann als techno- 
logiespezifische Netzliste (z.B. im EDIF oder VHDL-Format) ausge- 
geben werden. 


2.2 Einsatz der Syntheseprogramme 
In diesem und in allen weiteren Abschnitten zur Synthese von VHDL- 


Beschreibungen wird nur noch auf Werkzeuge eingegangen, die eine 
Umsetzung von einer RT-Beschreibung in eine Gatternetzliste unter- 
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stützen, da bei der Anwendung von VHDL z.Zt. diese Werkzeuge die 
größte Bedeutung haben. 


2.2.1 Umstellung von Schematic Entry 


Der Einsatz von Syntheseprogrammen bedeutet nicht, daß die kom- 
plette bisherige Entwurfsumgebung durch eine neue ersetzt wird. Nach 
[SYN 92] kann eine Umstellung vom gewöhnlichen Schematic-Entry 
(Graphische Schaltungseingabe auf Logikebene) auf die Synthese- 
werkzeuge in mehreren Schritten erfolgen: 


® Nachträgliche Optimierung der manuell erstellten Schaltungen 
mit Syntheseprogrammen, 


® nachträgliche Optimierung und Verbesserung der Testbarkeit, 
® _ teilweise Erfassung des Entwurfs mit VHDL und Synthese, 
® volle Beschreibung des Entwurfs mit VHDL und Synthese. 


Es ist zu beachten, daß auch durch die Verwendung von Synthese- 
werkzeugen Iterationszyklen nicht vermieden werden können. Diese 
spielen sich lediglich auf einer anderen Ebene ab ("We’ve got still the 
same problems, but on a higher level"). Die Synthesewerkzeuge bieten 
dem Entwickler aber die Möglichkeit, die Ebene des Entwurfs von der 
Logikebene auf die abstraktere Register-Transfer-Ebene zu verlagern, 
wodurch Komplexitäten besser beherrscht werden. Ganz losgelöst von 
der "Hardware" (der Logikebene) kann sich jedoch kein Entwickler 
bewegen, weil nur über die Analyse des Syntheseergebnisses auf Lo- 
gikebene auf eine geeignete VHDL-Modellierungstechnik auf RT- 
Ebene geschlossen werden kann. 


2.2.2 Zielsetzung 
Eine der wichtigsten Überlegungen beim Einsatz eines Synthesepro- 


gramms gilt dem Ziel, Einfluß auf die Optimierung der Schaltung zu 
nehmen. 
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2.2.2.1 Optionen und Randbedingungen 


Jedes Syntheseprogramm bietet die Möglichkeit, durch Einstellung 
von bestimmten Optionen Randbedingungen bzw. Optimierungskri- 
terien bei der Synthese vorzugeben (Setzen von "constraints"). Dies 
können neben der Auswahl von optimaler Fläche oder optimaler Lauf- 
zeit meist noch Laufzeitgrenzen für einzelne Pfade und weitere Rand- 
bedingungen, wie z.B. die Vorgabe einer Zustandscodierung, sein. 


Bei vielen Syntheseprogrammen zeigt sich jedoch, daß mit den jeweili- 
gen Einstellungen der Randbedingungen (Fläche, Laufzeit) nicht op- 
timal auf die Schaltung Einfluß genommen werden kann. Für die Ge- 
nerierung der Schaltung in Abhängigkeit von den Randbedingungen 
werden nämlich teilweise Heuristiken verwendet, so daß man nie sicher 
sein kann, wirklich die optimale Schaltung erzeugt zu haben. Eine 
Schaltung, die beispielsweise eine Laufzeitvorgabe von O ns (also mög- 
lichst schnell) hatte, kann langsamer sein als eine mit der Laufzeitvor- 
gabe 30 ns. 


2.2.2.2  Modellierungsstil 


Durch geschickte Verwendung von VHDL-Sprachelementen kann be- 
reits bei der Modellierung eine Entscheidung über eine mehr oder 
weniger geeignete Schaltungsarchitektur getroffen werden. Dazu ist 
erstens eine detaillierte Kenntnis von VHDL und zweitens das Wissen 
über die spätere Umsetzung der VHDL-Sprachkonstrukte durch das 
eingesetzte Synthesewerkzeug erforderlich. 


Beispiel: 


Einen Zähler kann man beispielsweise als Zustandsautomaten 
oder als sequentiellen Zähler modellieren, wobei nicht immer 
eine Beschreibungsart die optimale ist. In vielen Fällen, insbe- 
sondere bei 2er-Potenzen als Zähllängen, ergibt sich bei der se- 
quentiellen Beschreibung ein besseres Ergebnis, während bei 
Zähllängen, die knapp über einer 2er-Potenz liegen (z.B. 129), 
die Realisierung als Automat aufgrund der umfangreichen 
Minimierung der Übergangslogik (viele freie Zustände) günsti- 
ger ist. 
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Im folgenden soll deshalb anhand einiger VHDL-Beispiele illustriert 
werden, welchen Einfluß der Modellierungsstil und die gewählten 
Randbedingungen ("Constraints") auf das Syntheseergebnis haben. 


Für diese Betrachtungen wurden mehrere kommerzielle Synthesepro- 
gramme herangezogen, um programmspezifische Besonderheiten aus- 
mitteln zu können. Einschränkungen hinsichtlich der Verwendbarkeit 
von VHDL-Anweisungen und des Beschreibungsstils werden mit zu- 
künftigen Programmversionen zunehmend geringer werden. 


2.3 Synthese von kombinatorischen Schal- 
tungen 


In diesem Abschnitt soll dargestellt werden, wie VHDL-Modelle von 
kombinatorischen Funktionen in Schaltungsarchitekturen umgesetzt 
werden. Nähere Angaben finden sich in den Dokumentationen zu den 
jeweiligen Synthesewerkzeugen. 


2.3.1 Einführung 


In VHDL gibt es zwei Möglichkeiten, kombinatorische Schaltungen zu 
beschreiben: die Modellierung mit Hilfe nebenläufiger Anweisungen 
und mit Hilfe sequentieller Anweisungen (innerhalb von Prozessen 
und Unterprogrammen). 


Am einfachen Beispiel eines achtfachen NAND-Gatters (siehe Abb. C- 
6) sollen vier verschiedene Beschreibungsarten gezeigt werden. 


Dieses und alle weiteren VHDL-Beispiele verwenden dabei das IEEE- 
Package std_logic_1164 mit dem 9-wertigen Logiktyp 
std_ulogic. 
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Abb. C-6: Schaltbild des 8-fach NAND-Gatters 


y: 
END ENTITY; 


LIBRARY ieee; 
USE ijeee.std_logic_1164.ALL; 


ENTITY nand2 IS 
PORT (a,b: IN std_ulogic_vector (0 1 


OUT std_ulogic_vector (0 7 


Die Architekturen one und two verwenden die überladene Funktion 
NAND aus dem Package std_logic_1164 in vektorieller und Ein- 


zelbitversion. 


ARCHITECTURE 


one OF nand2 IS 


BEGIN 


END one; 


y <= a NAND b; 


ECTURE 


two OF nand2 IS 


ESS 
EGIN 
FOR i 


END PROC! 
END two; 


252 


(a,b) 


IN a'RANGE LOOP 


y(i) <= a(i) NAND b(i); 
END LOOP; 


ESS; 
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Die folgenden beiden Architekturen (three und four) verwenden 
logische Gleichungen zur Beschreibung der Funktion. Sie haben den 
Nachteil, daß im Rahmen einer funktionalen Simulation beim Auftre- 
ten von Signalen wie 'X', 'Z' oder 'H' an einem Eingang das Ver- 
halten des Gatters nicht korrekt modelliert ist, da in diesem Fall der 
Ausgang den Wert '1' annehmen würde. Infolgedessen ist es hier zu 
empfehlen, den vordefinierten NAND-Operator aus dem IEEE-Package 
(wie in Architektur one oder two) zu verwenden. 


ECTURE three OF nand2 IS 


<= '0' WHEN a(0)='1' AND b(0)='1' ELS 


y(7) <= '0' WHEN a(7)='1' AND b(7)='1' ELSE 
END three; 


ECTURE four OF nand2 IS 


ESS (a,b) 
EGIN 
FOR i IN a'RANGE LOOP 
CASE a(i) & b(i) IS 
WHEN "11" => y(i) <= '0'; 
WHEN OTHERS => y(i) <= '1'; 
END CASE; 
END LOOP; 
END PROCESS; 
END four; 


Bei der Synthese einer derart einfachen Beschreibung bestehen Keine 
Unterschiede in der Implementierung der verschiedenen Beschrei- 
bungsarten. Für die Architekturen three und four wird zwar zu- 
nächst eine recht komplizierte Schaltungsarchitektur generiert, diese 
dann aber bei der Optimierung wieder in acht einfache NAND-Gatter 
aufgelöst. Man benötigt mit diesen Versionen lediglich größere Re- 
chenzeiten bei der Synthese. 
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2.3.2 Verzweigungen 


Anhand des folgenden Modells wird betrachtet, wie die Verzweigungs- 
anweisungen IF und CASE in Hardware umgesetzt werden: 


ENTITY if_und_case IS 
PORT (i: IN integer RANGE 0 TO 9; 
a,b,c: IN std_ulogic_vector (7 DOWNT 
z: OUT std_ulogic_vector (7 DOWNT 
END if_und_case; 


if_variante if_und_case IS 


ESS (i,a,b,c) 


(1 = 3) TH 
ELSIF (i < 3) TH 
ELSE 
END IF; 


END PROCESS pl; 
D if_variante; 


ARCHITECTURE case_variante OF if_und_case IS 
BEGIN 
pl: PROCESS (i,a,b,c) 
BEGIN 
CASE i IS 
WHEN 3 => zZ 
WHEN 0 TO 2 => z 
WHEN OTHERS => z 
END CASE; 
END PROCESS pl; 
D case_variante; 


Die beiden Architekturen if_variante undcase_variante 
sind funktional identisch. Bei der Synthese jedoch werden unter- 
schiedliche Schaltungen erzeugt. Das liegt daran, daß eine IF-Anwei- 
sung grundsätzlich eine Priorität beinhaltet, nämlich die bevorzugte 
Abfrage des ersten Zweiges (hier: i=3). Bei der CASE-Anweisung 
sind dagegen alle Zweige gleichberechtigt. Nachstehende Schaltungen 
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ergeben sich zuerst aufgrund der obigen Beschreibungen. Bei der 
anschließenden Optimierung werden aber dann in der Regel wieder 
identische Schaltungen erzeugt. 


ARCHITECTURE if_variante ARCHITECTURE case_variante 
c ba chb a 


MUX 


Abb. C-7: Schaltbild der IF- und der CASE-Variante 


2.3.3 Signale und Variablen 


Bei der Beschreibung von Algorithmen ist normalerweise die Speiche- 
rung von Zwischenergebnissen notwendig. Dazu könnten prinzipiell 
Signale oder Variablen verwendet werden. Da Zuweisungen an Signale 
immer erst ein "Delta" später wirksam werden, führt der Einsatz von 
Signalen als Zwischenspeicher in Algorithmen jedoch häufig zu Mo- 
dellierungsfehlern und damit zu unerwarteten Syntheseergebnissen. 


Zur Illustration soll hier ein Beispiel gezeigt werden, bei dem mit Hilfe 
einer Schleife eine regelmäßige Schaltungsstruktur (XOR-Kette) be- 
schrieben werden soll: 


ENTITY kette IS 
PORT ( hbyte: IN std_ulogic_vector (0 TO 3) := "0000"; 


value: OUT std_ulogic ); 
END kette; 
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ARCHITECTURE richtig OF kette IS 
BEGIN 
PROCESS (hbyte) 
VARIABLE merker: std_ulogic : 
BEGIN 
merker := '0'; 
FOR i IN hbyte'RANGE LOOP 
merker := merker XOR hbyte (i); 
END LOOP; 


value <= merker; 
END PROCESS; 
D richtig; 


HITECTURE falsch OF kette IS 

IGNAL merker: std_ulogic : 

EGIN 

PROCESS (hbyte) 

BEGIN 
FOR i IN hbyte'RANGE LOOP 

merker <= merker XOR hbyte (i); 

END LOOP; 

END PROCESS; 

value <= merker; 

END falsch; 


Bei der Architektur richtig wird die Variable merker in der 
Schleife der Reihe nach mit allen Bits des Signals hbyte verknüpft, 
so daß primär bei der Synthese eine Kette von XOR-Gattern entsteht 
(siehe Abb. C-8). 


ARCHITECTURE richtig ARCHITECTURE falsch 
46: 
hbyte (0) Sur z L- ke 
hbyte (1) zZ 117 hbyte (3) — 
hbyte (2) — — — — — — —A I U ne 
hbyte (3) ——————— 7 
Abb. C-8: Syntheseergebnisse des VHDL-Modells kette 


256 © G. Lehmann/B. Wunder/M. Selz 


2 Synthese 


Bei der Architektur falsch hingegen werden Signale eingesetzt. Da 
Signalzuweisungen im Prozeß nicht sofort ausgeführt werden, werden 
die Zuweisungen an merker nicht wirksam, so daß nur noch eine 


Zuweisung, nämlich "merker <=merker XOR hbyte (3)" ver- 
bleibt, also ein einzelnes rückgekoppeltes XOR-Gatter. 


2.3.4 Arithmetische Operatoren 


Um die Probleme bei der Umsetzung von arithmetischen Operatoren 
näher zu beleuchten, wird das Beispiel eines 4-Bit-Volladdierers auf- 
gegriffen. Dessen Schnittstellenbeschreibung lautet: 


ENTITY addierer IS 
PORT ( a,b: IN std_logic_vector (3 DOWN 
cin: IN std_logic; 


Ss: OUT std_logic_vector (3 DOWN] 
cout: OUT std_logic ); 
END addierer; 


Die Eingangssignale a und b stellen die Summanden des Addierers 
dar. Die Ports cin und cout entsprechen dem Übertragsbit ("carry") 
auf der Ein- bzw. Ausgangsseite. Das vier Bit breite Ausgangssignal s 
schließlich steht für die Summe. 


Im folgenden werden verschiedene VHDL-Beschreibungen des Addie- 
rer-Verhaltens betrachtet. Die Architektur zwei_plus beschreibt 
den Addierer sehr einfach, indem die beiden Eingangssignale und der 
Carry-Eingang durch Hinzufügen von "0"-Stellen mit zwei Plus- 
zeichen verknüpft werden: 
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ARCHITECTURE zwei_plus OF addierer IS 
SIGNAL temp: std_logic_vector (4 DOWNTO 0); 


BEGIN 


temp <= ("0" & a) + ("O" & b) + ("0000" & cin); 
cout <= temp (4); -- Uebertrag 
s <= temp(3 DOWNTO 0); -- Summe 

END zwei_plus; 


Da zu erwarten ist, daß manche Syntheseprogramme aus zwei Plus- 
zeichen auch zwei Addierer aufbauen, wird die Beschreibung in der 
Architektur ein_plus auf ein Pluszeichen reduziert: 


ARCHITECTURE ein_plus OF addierer IS 
SIGNAL temp: std_logic_vector (5 DOWNTO 0); -- 6 Bit 
BEGIN 
temp <= ("O" & a& cin) + ("O0" aba "1"); 
cout <= temp (5); -- Uebertrag 
s <= temp(4 DOWNTO 1); -- Summe 
END ein_plus; 


Als Alternative zu diesen beiden funktionalen Beschreibungen kann 
man aber auch "hardware-orientiert" modellieren und beispielsweise 
direkt eine "Ripple-Carry-Struktur" vorgeben: 


ARCHITECTURE ripple OF addierer IS 
SIGNAL c: std_logic_vector (3 DOWNTO 0); 
BEGIN 


s <= (a XOR b) XOR (c(2 DOWNTO 0) & cin); 
c <= ((a XOR b) AND (c(2 DOWNTO 0) & cin)) OR (a AND b); 
cout <= c (3); 

END ripple; 


Natürlich kann man alternativ auch eine "Carry-Look-Ahead-Struktur" 
beschreiben: 
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ARCHITECTURE cla OF addierer IS 

SIGNAL c: std_logic_vector (2 DOWNT 
SIGNAL p,g: std_logic_vector (3 DOWNT 
EGIN 


p<=axXOR b; 
g <= a AND b; 


s<=pXOR (c & cin); 
OR 
OR 
OR 
cout OR 
END cla; 


Bei der Synthese der verschiedenen Architekturen ergibt sich, daß mit 
ein_plus meistens bessere Ergebnisse erreicht werden als mit 
zwei_plus. Abb. C-9 zeigt die Ergebnisse (Fläche in Gatteräquiva- 
lenten, GÄ; Laufzeit in ns) bei der Synthese von 4-Bit- und 32-Bit- 
Addierern mit den vier unterschiedlichen Architekturen, jeweils auf 
minimale Fläche (4F, 32F) bzw. minimale Laufzeit (4L, 32L) opti- 
miert: 


ARCHITECTURE ARCHITECTURE 
zwei_plus ripple 


4L 89GÄ 3,2ns aL 142GÄ 2,0ns 
aF 54GÄ 6,0ns 4F 41GÄ 5,3ns 
32L 741GÄ 9,0ns 32L 497 GÄ 14,6ns 
32F 432 GÄ 33,3 ns ENTITY 32F 331 GÄ 45,9 ns 


addierer 


ARCHITECTURE ARCHITECTURE 
ein_plus cla 


aL 92GÄ 2,7ns aL 104GÄ 2,3 ns 
4F 36GÄ 4,9ns 4F 35GÄ 4,9ns 
32L 568GÄ 5,3ns 32L 538GÄ 6,2ns 
32F 286 GÄ 30,5 ns 32F 273GÄ 23,0 ns 


Abb. C-9: Syntheseergebnis verschiedener Addiererarchitekturen 


Abb. C-9 zeigt, daß sich das Syntheseergebnis sowohl durch die 
"constraints" (Optimierungsbedingungen) als auch durch den Model- 
lierungsstil erheblich beeinflussen läßt. Dies gilt für alle betrachteten 
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Syntheseprogramme. Besonders fällt hier auf, daß die Architektur cla 
(Carry-Look-Ahead) meist auf eine kleinere Schaltung als die Ripple- 
Carry-Architektur führt. Beim manuellen Entwurf hätte man durch 
Einsatz einer Ripple-Carry-Architektur eine kleinere Schaltung erzielt 
als mit der Carry-Look-Ahead-Architektur. Dies zeigt, daß die Synthe- 
seprogramme die gegebenen Gleichungen nicht als Addierer erkennen 
können und in diesem Fall die Gleichungen für den Carry-Look- 
Ahead-Addierer offensichtlich mehr Spielraum für die Flächenopti- 
mierung bieten. 


Bei neueren Versionen der Syntheseprogramme ist die Verwendung 
von arithmetischen Operatoren sinnvoller ist als die Angabe von logi- 
schen Gleichungen, da die Programme oft optimierte Module für die 
Synthese von arithmetischen Operatoren zur Verfügung stellen. 


2.3.5 Schleifen 


Von den drei Schleifenarten, die in VHDL möglich sind (FOR- 
Schleife, WHILE-Schleife und Endlosschleife) wird nur die FOR- 
Schleife von den Syntheseprogrammen uneingeschränkt unterstützt, 
weil hier die Anzahl der Schleifendurchläufe vor der Ausführung der 
Schleife bekannt ist. 


Das folgende Beispiel zeigt, wie durch einen für die Simulation kor- 
rekten, aber für die Synthese ungünstigen Einsatz von Schleifen ein 
hoher Flächenaufwand impliziert wird. Dazu soll das Modell eines 
Barrel-Shifters betrachtet werden, der 8-Bit breite Daten (data_in) 
in Abhängigkeit von einem Steuersignal (adresse) um bis zu sieben 
Stellen rotieren kann. 


ENTITY barrel IS 
PORT (data_in : IN std_ulogic_vector (7 DOWNTO 0); 


adresse : IN std_logic_vector (2 DOWNTO 0); 
data_out : OUT std_ulogic_vector (7 DOWNTO 0)); 
END barrel; 
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ARCHITECTURE eins OF barrel IS 
SIGNAL adr : integer RANGE 0 TO 7 


B 


adr <= conv_integer (adresse); Konvertierung in integer 

PROCESS (data_in, adr) 

BEGIN 
FOR i IN 7 DOWNTO O0 LOOP 

data_out ((i + adr) mod 8) <= data_in(i); 

END LOOP; 

END PROCESS; 

END eins; 


ARCHITECTURE zwei OF barrel IS 


SIGNAL adr : integer RANGE 0 TO 7; 


B 


ESS (data_in, adresse) 
VARIABLE puffer : std_ulogic_vector (7 DOWNTO 0); 


puffer := data_in; 
FOR i IN 0 TO 2 LOOP 
IF (adresse (i) = '1') THEN 
puffer := puffer (7-2**i DOWNTO 0) & 
puffer (7 DOWNTO 7-2**i+1); 


END IF; 
END LOOP; 

data_out <= puffer; 
END PROCESS; 
END zwei; 


Bei der Synthese der Architektur eins ist zu erkennen, daß für jeden 
Schleifendurchlauf ein eigener Addierer generiert wird, also insgesamt 
acht Addierer entstehen. Zwar können diese Addierer bei entsprechen- 
der Optimierungseinstellung zum Teil wieder reduziert werden, aber 
die Schaltung bleibt für immer größer und langsamer als bei geschick- 
ter Modellierung unter Verwendung einer Puffervariablen (Architekur 
zwei). Eine Untersuchung der Synthese mit fünf verschiedenen 
Beschreibungsvarianten für einen 32-Bit-Linksrotierer ergab Gatter- 
äquivalente zwischen 480 und 3096 und Laufzeiten zwischen 9,5 und 
72,5 ns. Hieraus wird ersichtlich, daß man, zumindest in einigen extre- 
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men Fällen, durch ungeschickte Modellierung einige 100% an zusätz- 
licher Logik erzeugen kann. 


Die Ergebnisse können dahingehend verallgemeinert werden, daß 
Schleifen zur Verarbeitung von einzelnen Signalen vermieden werden 
sollten, da dies zu einer Vervielfachung der Hardware führt. 


2.3.6 Zusammenfassung 


Nach Untersuchung einer Vielzahl von kombinatorischen Schaltungen 
unter Verwendung von diversen Modellierungsarten zeichnen sich fol- 
gende Ergebnisse ab: 


I Beikleinen Schaltungen hängen die Syntheseergebnisse nicht 
von der Art der Beschreibung ab. Es spielt also keine Rolle, ob 
eine bestimmte Funktion mit IF, CASE, SELECT oder durch 
direkte Angabe der logischen Funktion mit arithmetischen und 
Booleschen Operatoren beschrieben wird. 


I Bei großen Schaltungen hingegen ist eine tabellarische Be- 
schreibung der Funktion mit Hilfe von sequentiellen Anweisun- 
gen (IF, CASE etc.) kaum noch möglich. Hier müssen mög- 
lichst einfache und kompakte Operatoren gewählt werden. Ge- 
genüber eigenen Beschreibungen der Funktionalität haben diese 
Operatoren darüberhinaus den Vorteil, daß sie vom Synthese- 
programm besser interpretiert werden können, d.h. durch geeig- 
netes Setzen von "constraints" kann man i.d.R. die Optimie- 
rungsziele leichter erreichen. 


I Innerhalb algorithmischer Beschreibungen sollten Variablen 
verwendet werden. Das Ergebnis des Algorithmus wird dann den 
Signalen oder Ports zugewiesen (vgl. Beispiel "kette"). 


I In einigen Fällen Kann man durch eine komplexere, hardware- 
nähere Modellierung auch ein besseres Syntheseergebnis erzie- 
len (sieht man vom Beispiel des "Ripple-Carry-Addierers" ein- 
mal ab). 


I Beim Einsatz von Schleifen zur Abarbeitung der einzelnen Ele- 
mente eines Vektors wird oft vielfache Logik erzeugt (vgl. Bsp. 
"barrel"). Schleifen sollten deshalb nur dann eingesetzt wer- 
den, wenn genau dieses erwünscht ist (vgl. Bsp. "kette"). 
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2.4 Synthese von sequentiellen Schaltungen 
2.4.1 Latches 


Gegeben sei folgende VHDL-Beschreibung: 


ENTITY was_ist_das IS 
PORT ( a,b: IN bit; 
e: OUT bit ); 


END was_ist_das; 


ARCHITECTURE behave OF was_ist_das IS 
BEGIN 

PROCESS (a,b) 
EGIN 
IF 
EN 


Wenn das Signal a auf '0"' liegt, wird dem Ausgang c der Wert des 
Eingangs b zugewiesen. Im Falle a = '1"' erfolgt keine explizite Zu- 
weisung des Ausgangs c, so daß der vorhergehende Wert beibehalten 
wird. Dies bedeutet aber wiederum, daß der Wert gespeichert werden 
muß. Folglich beschreibt das obige Modell ein Speicherelement, ein 
D-Latch (Abb. C-10). Bei diesem Latch ist a das Enable-Signal, b der 
Dateneingang und c der Ausgang. Bei a = '0' ist das Latch transpa- 
rent, so daß alle Änderungen des Eingangs b sofort am Ausgang c er- 
scheinen. Bei a= '1' ist das Latch gesperrt (Halten), so daß Ände- 
rungen des Eingangs b sich nicht auf den Ausgang c auswirken. 


b 1D .Q c 
a QC1 


Abb. C-10: Schaltbild eines D-Latch 
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Aus dieser Beschreibung kann man nicht nur ableiten, wie man prin- 
zipiell ein Latch modelliert, sondern auch die Gefahr der Synthese un- 
erwünschter Speicherelemente bei unvollständigen IF-Anweisungen 
in VHDL-Modellen erkennen. Immer dann, wenn in einer IF-Anwei- 
sung bestimmte Signale nur in einem Teil der Zweige auf der linken 
Seite von Signalzuweisungen stehen, muß ein Speicherelement erzeugt 
werden. Dies gilt auch für unvollständige Zuweisungen in CASE-An- 
weisungen. 


2.4.2 Flip-Flops 


Flip-Flops unterscheiden sich von Latches durch ihre Taktflanken- 
steuerung. Zur Modellierung muß ein Pegelübergang an einem Takt- 
signal erkannt werden, wozu sich das VHDL-Attribut EVENT eignet. 
Dieses Attribut bezieht man auf das Taktsignal und plaziert es in ei- 
nem Prozeß entweder in einer WAIT- oder in einer IF-Anweisung: 


ENTITY dff IS 
PORT (clk,d: IN std_ulogic; 
q: OUT std_ulogic); 


END dff; 


ARCHITECTURE variantel OF dff IS 
BEGIN 

PROCESS 

BEGIN 
WAIT UNTIL clk'EVENT AND clk = '1'; 
q<=d; 
END PROCESS; 
END variantel; 
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ECTURE variante2 OF dff IS 


ESS (clk) 


clK'EVENT AND clk = '1' TH 
qı=d 

END IF; 

EN! ESS; 
D variante2; 


Beide Architekturen beschreiben ein D-Flip-Flop. Streng genommen 
sind sie jedoch nicht ganz korrekt, denn der Fall eines Wechsels am 
Signal clk von 'X' nach '1"' ist nicht erfaßt. Die Beschreibungen 
würden dann fälschlich eine steigende Taktflanke erkennen. Eine zu- 
sätzliche Überprüfung, ob das Taktsignal vorher '0' war, kann mit 
Hilfe des Attributs LAST_VALUE geschehen: 


ECTURE variante3 OF dff IS 


WwAIT UNTIL c1lK'EVENT AND clk = '1' 
AND clk'LAST_VALU. 


q<=d 
END PROCESS; 
D variante3; 


ECTURE variante4 OF dff IS 


ESS (clk) 


clk'EVENT AND clk = '1' AND clk'LAST_VALU 
THEN q <= d; 

END IF; 

END PROCESS; 

variante4; 
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Da eine Erkennung von steigenden oder fallenden Flanken eines 
Signals häufig benötigt wird, sind die zwei Funktionen RISING 
_EDGE und FALLING_EDGE in das IEEE-Package integriert wor- 
den. Sie enthalten die Beschreibung gemäß variante4 und geben 
ein Signal vom Typ boolean zurück, welches true ist, wenn eine 
steigende bzw. fallende Flanke erkannt wurde. Allerdings wird das 
Attribut LAST_VALUE, und damit auch diese beiden Funktionen, 
nicht von allen Syntheseprogrammen unterstützt. 


Wenn man statt des D-Flip-Flops ein T-Flip-Flop (Toggle-Flip-Flop) 
beschreiben möchte, kann man die folgende Architektur verwenden. 


ENTITY t_ff IS 

PORT (clk, enable: IN std_ulogic; 
q: BUFFER std_ulogic : 

END t_ff; 


ARCHITECTURE behavioral OF t_ff IS 
EGIN 
PROCESS 
BEGIN 
wWAIT UNTIL clk'EVENT AND clk = '1' AND 
clk'LAST_VALUE = '0'; 
IF enable = '1' THEN q <= not g; 
END IF; 
END PROCESS; 
D behavioral; 


Mit dieser Beschreibung wird von den Syntheseprogrammen entweder 
ein Toggle-Flip-Flop oder, falls ein solches in der Technologiebi- 
bliothek nicht vorhanden ist, ein D-Flip-Flop mit vorgeschaltetem 
XOR-Gatter eingesetzt. 


Zu beachten ist, daß gewünschte asynchrone Eingänge von Speicher- 
elementen nicht automatisch von einem Syntheseprogramm erzeugt 
werden, sondern in VHDL beschrieben werden müssen. Am Beispiel 
eines D-Flip-Flops mit asynchronem Rücksetzeingang sei dies gezeigt: 
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ENTITY dff IS 
PORT (clk,d,reset: IN std_ulogic; 
q: OUT std_ulogic ); 


END dff; 


ARCHITECTURE async_reset OF dff IS 

BEGIN 
PROCESS (clk,reset) 
BEGIN 

IF reset = '0' THEN low-aktives Reset 

q <= '0'; -- hat erste Prioritaet 

ELSIF cl1k'EVENT AND clk = '1' AND -- Abfrage auf Taktf]l. 

clk'LAST_VALUE = '0' THEN -- nur, wenn kein reset 

q<=d; 

END IF; 

END PROCESS; 

D async_reset; 


2.4.3 Zustandsautomaten 


Bei der Modellierung von endlichen Zustandsautomaten (FSM) muß 
man zwischen Mealy-, Moore- und Medvedev-Automaten unterschei- 
den. Bei einem Mealy-Automaten hängt der Ausgangsvektor vom 
momentanen Zustand und vom Eingangsvektor ab, beim Moore- 
Automaten dagegen nur vom Zustand. Ein Medvedev-Automat ist da- 
durch gekennzeichnet, daß jeder Ausgang des Automaten mit dem 
Ausgang eines Zustands-Flip-Flops identisch ist. Abb. C-11 beschreibt 
ein Blockschaltbild für den Mealy-Automatentyp. 


Zustands- 
speicher 


Eingangs- Ausgangs- 
variablen variablen 
Abb. C-11: Blockschaltbild eines Zustandsautomaten (Mealy) 
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Die folgenden drei VHDL-Prozesse zeigen die prinzipielle, synthese- 
gerechte Modellierung eines Mealy-Automaten. Die Blöcke aus Abb. 
C-11 sind hier in getrennten Prozessen realisiert. 


zustandsspeicher: PROCI (clk 

BEGIN 
IF (reset = '1') THEN 
zustand <= reset_zustand; 

ELSIF (clk'event AND clk='1!' 

THI 

END IF; 

D PROCESS zustandsspeicher; 


uebergangslogik: PROC 
BEGIN 
CASI 

W 


zustand IS 
EN zustandl => 
IF . AND in2 


(inl 
TH 


ELSIF 


WHEN zustand2 => 


END CASE; 
D PROCESS uebergangslogik; 


ausgabelogik: PROCESS (zustand, 


BEGIN 
CASI 


W 


zustand IS 
EN zustandl => 
IF .„ AND in2 


(inl 
THEN outl1 <= ...; 


ELSIF 


WHEN zustand2 => 


END CASE; 
D PROCESS ausgabelogik; 
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(zustand, 


, keset) 


AND clk'LAST_VALU 


EN zustand <= folge_zustand; 


inl, in2, 


EN folge_zustand <= ...; 


äinl, in2; 


out2 <= 
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Da die Prozesse zur Beschreibung der Übergangslogik und der Aus- 
gabelogik sehr ähnlich sind, können sie auch zusammengefaßt werden. 
Eine mögliche Fehlerquelle hierbei ist, daß Latches für die Ausgänge 
erzeugt werden, wenn diese nicht in jedem Zustand und bei jeder 
Kombination der Eingangssignale einen Wert zugewiesen bekommen. 


Wenn man versucht, die FSM komplett in einem Prozeß zu modellie- 
ren, der lediglich vom Takt und dem Rücksetzsignal getriggert wird, 
werden Flip-Flops für die Ausgänge erzeugt. Als Folgerung daraus 
kann man empfehlen, bei Mealy- und Moore-Automaten einen Prozeß 
für die Zustandsspeicherung und einen weiteren Prozeß für den rein 
kombinatorischen Teil zu verwenden. 


2.5 Optimierung der "Constraints" 


Neben der Optimierung des VHDL-Modells können zur Verbesserung 
der Syntheseresultate bei jedem Syntheseprogramm eine Reihe von 
Optionen angegeben werden, mit denen man die gewünschte Ziel- 
setzung bei der Synthese näher spezifizieren Kann (sog. "constraints"). 


2.5.1 Ziele und Randbedingungen 
Grundlegende Ziele bei der Synthese sind neben einer funktionieren- 
den Schaltung: 


I geringer Flächenbedarf, 
A hohe Geschwindigkeit, 
I geringe Verlustleistung. 


Daneben lassen sich auch viel detailliertere Angaben machen: 


I Festlegung der Treiberstärken an den primären Eingängen, 


I Festlegung der Lastkapazitäten an den primären Ausgängen, 


a Angabe von Schätzwerten bzw. Modellen zur Berücksichtigung 
von Leitungskapazitäten, 


m) Angaben zur Schwankungsbreite der Laufzeiten durch Variation 
von Temperatur, Versorgungsspannung und Prozeß. 
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Die angegebenen "constraints" beziehen sich auf die gesamte Schal- 
tung. Meist ist es aber wünschenswert, sie speziell auf einen Teil der 
Schaltung zu beziehen. Denkbar wäre die Angabe einer maximalen 
Verzögerungszeit von einem Eingang zu einem Ausgang bei sonst 
möglichst kleiner Schaltung. 


2.5.2 Constraint-Strategien 


Es ist i.d.R. nicht sinnvoll, "constraints" für die Synthese intuitiv zu set- 
zen. Die Erfahrung zeigt, daß man bessere Schaltungsergebnisse erhält, 
wenn man Randbedingungen nicht auf unmögliche Werte setzt (z.B. 
Laufzeit O ns), sondern Werte nahe des Machbaren verwendet. Dies 
liegt u.a. daran, daß bei unmöglichen Angaben die Gewichtungen bei 
den heuristischen Methoden der Synthesewerkzeuge ungünstig gesetzt 
werden. 


Durch den Trade-Off Fläche-Geschwindigkeit liegen die optimalen 
Lösungen einer gegebenen Schaltung, aufgetragen in einem Dia- 
gramm Laufzeit über Fläche, auf einer Hyperbel. Da in der Praxis eine 
endliche Anzahl von nicht immer optimalen Syntheseergebnissen vor- 
liegt, erhält man eine Reihe von diskreten Lösungen im sog. Entwurfs- 
raum. 


Abb. C-12 zeigt den Entwurfsraum eines Zustandsautomaten. Die 
Punkte im Entwurfsraum wurden durch viele Syntheseläufe einer 
VHDL-Beschreibung unter Verwendung verschiedenster "constraints" 
generiert. Leider steht ein solcher Überblick über die möglichen Lö- 
sungen zu Beginn der Synthese nicht zur Verfügung. 


Das Ziel beim Einsatz von "constraints" ist es, dem Syntheseprogramm 
mitzuteilen, welche Realisierung gewünscht wird. Man kann allerdings 
kaum vorhersagen, welche "constraints" zu welcher Schaltung führen, 
so daß ein iteratives Vorgehen notwendig wird. 


Man geht dabei sinnvollerweise so vor, daß man mit realen, d.h. leicht 
verwirklichbaren "constraints" beginnt und diese so lange verschärft, 
bis das Syntheseprogramm keine bessere Schaltung mehr liefert. 
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Abb. C-12: Entwurfsraum eines Zustandsautomaten 


Am Beispiel des Zustandsautomaten sollen einige mögliche Strategien 
dargestellt und bewertet werden. Die Ergebnisse haben keine allgemei- 
ne Gültigkeit, sollen jedoch die grundsätzliche Problematik aufzeigen. 


2.5.2.1 Laufzeit Null 


Eine einfache Strategie besteht darin, die gewünschte Laufzeit der 
Schaltung, ohne Abschätzung der tatsächlich machbaren Laufzeit, auf 
"Null" zu setzen. Abb. C-13 zeigt das Ergebnis dieser Strategie im 
Entwurfsraum des erwähnten Beispiels (schwarz ausgefüllter Kreis). 


Laufzeit / [ns] 


120 130 140 150 160 
Fläche / [GÄ] 


Abb. C-13: Ergebnis der Strategie "Laufzeit Null" 
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Wie aus der Abbildung ersichtlich ist, führt diese Strategie keineswegs 
zu einem guten Resultat. 


2.5.22 Laufzeit "in der Nähe des Machbaren" 


Eine andere Strategie besteht darin, ein Laufzeit-Constraint "in der 
Nähe des Machbaren" zu setzen. Hintergrund ist, daß bei der Verfol- 
gung dieser Strategie die Gewichtungsfaktoren bei der Optimierung 
eine bessere Wirkung zeigen als bei der zu starken Gewichtung der 
Null-Laufzeit. Diese Strategie wird auch von vielen Synthesepro- 
grammherstellern empfohlen. 


Für den vorliegenden Fall wurde das Laufzeit-Constraint einmal auf 
3 ns und einmal auf 4 ns gesetzt. Die Ergebnisse sind als schwarz aus- 
gefüllte Kreise in Abb. C-14 aufgetragen. 
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Abb. C-14: Ergebnisse der Strategie "machbare Laufzeit" 


Auch damit werden nicht die schnellsten Schaltungen generiert. Viel- 
mehr erhält man ähnliche Ergebnisse wie bei der ersten Strategie. 


2.5.2.3  Mehrfache Optimierung 


Eine weitere Strategie besteht darin, das Ergebnis obiger Strategien 
durch mehrere aufeinanderfolgende Syntheseläufe zu optimieren. 
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Eine neunfache Optimierung des Zustandsautomaten, auf der Basis der 
Laufzeit 3 ns, führt auf die in Abb. C-15 dargestellten Ergebnisse 
innerhalb des Entwurfsraums (schwarz ausgefüllte Kreise). 
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Abb. C-15: Ergebnisse der Strategie "mehrfache Optimierung" 


Mit dieser Strategie erhält man eine der schnellsten Schaltungen im 
Feld mit ca. 4 ns Laufzeit. Aufgrund der mehrfachen Optimierung er- 
geben sich jedoch deutlich höhere Rechenzeiten. Außerdem läßt sich 
nicht vorhersagen, nach welcher Iteration das beste Ergebnis, d.h. ein 
globales Minimum, erreicht wird. 


Abb. C-16 zeigt die nach jedem Iterationsschritt erreichte Laufzeit: 
[| 
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> 


Iteration 


Laufzeit / [ns] 


Abb. C-16: Laufzeit bei mehrfacher Zeitoptimierung 
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An den Ergebnissen des Beispiels läßt sich erkennen, daß eine wieder- 
holte Optimierung nicht immer den gewünschten Erfolg mit sich 
bringt. Eine mehrfache Optimierung ist jedoch trotz erhöhter Rechen- 
zeiten dem blinden Vertrauen auf ein gutes Ergebnis nach nur einem 
Syntheselauf vorzuziehen. 


2.6 Ressourcenbedarf bei der Synthese 


Neben den Performancedaten der von einem Syntheseprogramm er- 
zeugten Schaltung spielt auch der Zeitbedarf für die Synthese eine 
wichtige Rolle. Kann bei einzelnen Syntheseläufen eine hohe Rechen- 
zeit vielleicht noch akzeptiert werden, so wird bei größeren Entwürfen 
und mehreren Synthesedurchläufen der Faktor Rechenzeit unmittelbar 
bestimmend für die gesamte Entwurfszeit. Daneben spielen auch An- 
forderungen an die benötigte Hardwareplattform, der erforderliche 
Arbeits- und Swap-Speicher und der vom Programm benötigte Spei- 
cherplatz eine Rolle. 


Verfügbare Syntheseprogramme bieten leider keine Möglichkeit, die 
Rechenzeit abzuschätzen oder gar ein Limit dafür zu setzen. Es ist le- 
diglich möglich, die Anzahl der Optimierungszyklen durch Optionen 
auf niedrig, mittel oder hoch einzustellen. Der Anwender sollte also 
vor dem Start des Syntheseprozesses eine Vorstellung von der für die 
Synthese benötigten Rechenzeit haben. Die wichtigsten Einflußfak- 
toren dafür sind: 


I Leistungsfähigkeit der Rechnerumgebung, 
Art des Syntheseprogramms, 
Art der VHDL-Beschreibung, 


gesetzte "constraints", 


In en a En | 


verwendete Technologiebibliothek. 


Die folgenden beiden Abbildungen zeigen die benötigte Rechenzeit 
(reine CPU-Zeit) für drei verschiedene Schaltungen, abhängig von der 
Größe der Schaltung, einmal für Flächenoptimierung und einmal für 
Laufzeitoptimierung. Zur Synthese wurde ein Rechner vom Typ SUN 
Sparc IPX mit 32 MB Arbeitsspeicher verwendet. 
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Abb. C-17: CPU-Zeit bei Flächenoptimierung 
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Abb. C-18: CPU-Zeit bei Laufzeitoptimierung 


Die beiden Abbildungen zeigen deutlich, daß die Laufzeitoptimierung 
sehr viel mehr CPU-Zeit erfordert als die Optimierung auf geringste 
Fläche. Bei den dargestellten Schaltungen, die sich im Bereich von ein- 
igen hundert Gatteräquivalenten bewegen, ist ein Unterschied bis etwa 
zum Faktor 10 festzustellen, während bei größeren Schaltungen (meh- 
rere tausend Gatteräquivalente) Unterschiede bis zum Faktor 100 auf- 
treten. 


Außerdem zeigen die letzten beiden Abbildungen, daß die Rechen- 
zeiten für die Addierer- und Komparatorschaltung weit weniger von 
der Schaltungsgröße abhängig sind als die der Zählerschaltung. Ur- 
sache hierfür ist, daß das Synthesewerkzeug bei Addierern und Kom- 
paratoren auf programminterne Makros zurückgreifen kann. 
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1 Packages 


1.1 Das Package standard 


Das Package standard liegt meist nicht in Textform vor, sondern ist 
im Simulations- bzw. Syntheseprogramm integriert. Es werden in der 
Version Yg7 folgende Basistypen deklariert: 


YPE boolean IS (false, true); 
YPE bit 15042 PEN 5 
YPE character IE 244007 -- 128 ASCII-Character 


YPE severity_level IS (note, warning, error, failure); 
YPE integer IS RANGE ... ; -- rechnerabhängig 


YPE real IS RANGE ... ; -- rechnerabhängig 
SUBTYPE natural IS integer RANGE 0 TO integer'HIGH; 
SUBTYPE positive IS integer RANGE 1 TO integer'HIGH; 
YPE time IS RANGE ... -- rechnerabhängig 
UNITS £s; 


£s; 
PS; 
ns; 
us; 
ms; 
60 sec; 
60 min; 
END UNITS; 
YPE string IS ARRAY (positive RANGE <>) OF character; 
YPE bit_vector IS ARRAY (natural RANGE <>) OF bit; 


Weiterhin werden folgende Operatoren deklariert: 


I logische Operatoren für Operanden vom Typ bit, bit_vec- 
tor undboolean, 


I die Vergleichsoperatoren für alle deklarierten Typen, 


I sämtliche mathematische Operatoren für die Typen integer 
und real, 
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I Multiplikations- und Divisionsoperator für einen time-Ope- 
rand und einen integer- oder real-Operand, 


I der "concatenation"-Operator (&) für Operanden vom Typ 
character und string bzw. Kombinationen von beiden, 
für bit und bit_vector bzw. Kombinationen von beiden 
und 


a die Funktion now, die die aktuelle Simulationszeit liefert. 


1.2 Das Package textio 


Das Package textio stellt einige einfache Funktionen zum Lesen 
und Schreiben von Informationen in Dateien vom Typ text bereit. 
Die Vorgehensweise bei der Kommunikation mit solchen Dateien wur- 
de bereits in Teil B behandelt. Das Package enthält in der Version Yg7 
folgende Typen: 


YPE line ACCESS string; 
IYPE text IS FILE OF string; 
YPE side IS (right, left); 
SUBTYPE width IS natural; 

FILE input : text IS IN "STD_INPUT"; 
FILE output : text IS OUT "STD_OUTPUT"; 


Um zeilenweise aus einem File zu lesen bzw. in ein File zu schreiben 
und um das Ende von Files zu erkennen sind folgende Funktionen 
und Prozeduren implementiert: 


PROCEDURE readline (f£f : IN text; : OUT line); 


1 
PROCEDURE writeline (£f : OUT text; 1 : IN line); 
RI 


FUNCTION endfile (£ : IN text) ETURN boolean; 


Prozeduren zum Lesen aus den Zeilen werden für alle Basistypen aus 
dem Package standard (bit, bit_vector, boolean, inte- 
ger,real,character, string, time) jeweils mit und ohne 
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Prüfwert good deklariert. Zum Erkennen des Zeilenendes existiert 
wiederum eine Funktion (endline): 


read (1 : INOUT line; value : OU1 
read (1 : INOUT line; value : OU1 
good : OUT boolean); 


-- read-Funktionen fuer andere Typen 


FUNCTION endline (1 : IN line) RETURN boolean; 


Auch Prozeduren zum Schreiben in die Zeile sind für alle Basistypen 
aus standard vorgesehen. Dabei können optional die zu schreiben- 
den Daten innerhalb eines Bereiches (Bereichslänge: field) über 
den Parameter justified ausgerichtet werden: 


BE write (1 : INOUT line; value : IN bit; 
justified : IN side:=right; field : IN width:=0); 


-- write-Funktionen fuer andere Typen 


Besonderheiten ergeben sich beim Schreiben von Objekten der Typen 
real und time. 


BE write (1 : INOUT line; value : IN real; 
justified : IN side:=right; field : IN width:=0; 
digits : IN natural := 0); 
BE write (1 : INOUT line; value : IN time; 
justified : IN side:=right; field : IN width:=0; 
unit : IN time := ns); 


Bei reellen Zahlen kann die Zahl der Nachkommastellen (digits) 
angegeben werden. Der Defaultwert O bedeutet, daß das Objekt in der 
Exponentialform (z.B. 1.987456E-17) geschrieben wird. 
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Bei Objekten des Typs time wird mit der optionalen Angabe von 
units die Einheit festgelegt, in der der Objektwert gespeichert wird. 
Defaultwert hierfür ist ns (Nanosekunden). 


1.3 IEEE-Package 1164 


Das 9-wertige Logiksystem im Package std_logic_1164 wurde 
vom IEEE entwickelt und normiert, um einen Standard für Logikgat- 
ter zu setzen, die genauer modelliert sind, als dies eine zweiwertige Lo- 
gik zu leisten vermag. Die hier beschriebenen Deklarationen und 
Funktionen beziehen sich auf die Version 4.200 des Packages. 


Der Basistyp des Logiksystems std_ulogic (u steht für "unre- 
solved"), ist als Aufzähltyp der folgenden Signalwerte deklariert: 


E std_ulogic IS ( Uninitialized 
Forcing Unknown 
Forcing 0 
Forcing 1 


High Impedance 
Weak Unknown 
Weak 0 

Weak 1 

Don't care 


Die unterschiedlichen Signalwerte haben folgende Bedeutung: 

a Starke Signalwerte ('0', '1', 'x"') beschreiben eine Techno- 
logie, die aktiv die Pegel “High” und ‘Low’ treibt (Totem-Pole- 
Endstufen, CMOS). 

a Schwache Signale ('L', 'H', 'w') dienen für Technologien 


mit schwach treibenden Ausgangsstufen (z.B. NMOS-Logik mit 
Widerständen als Lastelemente). 


I Mit dem Wert 'z' können Tristate-Ausgänge beschrieben wer- 
den. 


I Der Wert 'U"' kennzeichnet nichtinitialisierte Signale. 


A Der Wert '-"' dient zur Kennzeichnung von "don't cares", die 
bei der Logikoptimierung verwendet werden. 
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Dieser Logiktyp, davon abgeleitete Untertypen, zugehörige Konver- 
tierungsfunktionen, Operatoren und "resolution functions" werden im 
Package std_logic_1164 deklariert und die Funktionen im zuge- 
hörenden Package Body definiert. 


Folgende abgeleitete Typen des Basistyps std_ulogic sind im 
Package deklariert: 


TYPE std_ulogic_vector IS ARRAY 
( natural RANGE <> ) OF std_ulogic; 
FUNCTION resolved ( s : std_ulogic_vector ) 
RETURN std_ulogic; 
YPE std_logic IS resolved std_ulogic; 


E std_logic_vector IS ARRAY 

( natural RANGE <> ) OF std_logic; 
YPE X01 IS resolved std_ulogic RANGE 'X' TO '1'; 
YPE X012 IS resolved std_ulogic RANGE 'X' TO '2'; 
YPE UXO1l resolved std_ulogic RANGE 'U' TO '1'; 
YPE UX012 resolved std_ulogic RANGE 'U' TO '2'; 


Die Untertypen X01,X012, UX01 und UX012 bilden mehrwertige 
Logiksysteme, die auf die schwach treibenden Signalwerte und das 
"don't care" verzichten. 


Für den Basistyp std_ulogic (und damit implizit auch für dessen 
Untertypen std_logic,X01,X012, UX01 und UX012), die 
Vektortypen std_ulogic_vector und std_logic_vector 
sind die folgenden, überladenen Operatoren definiert: 

7 " NOT" m) " AND " 7 " NAND " 


7 "OR" a "NOR" 7 " xXOR" 
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Am Beispiel des Operators "NAND" sollen die existierenden Varianten 
für die diversen Operandentypen gezeigt werden: 


TION "NAND" ( 1 : std_ulogic; r : std_ulogic ) 
RETURN UX01; 

TION "NAND" ( 1, r : std_logic_vector |) 
RETURN std_logic_vector; 
TION "NAND" ( 1, r : std_ulogic_vector ) 
RETURN std_ulogic_vector; 


Die Funktion xnor wird in der hier beschriebenen Package-Version 
für die 9-wertige Logik ebenfalls definiert, allerdings nicht als Opera- 
tor, sondern als herkömmliche Funktion: 


TION xnor ( 1: std_ulogic; r : std_ulogic ) 
RETURN UX01; 

TION xnor (1, r : std_logic_vector |) 
RETURN std_logic_vector; 
TION xnor ( 1, r : std_ulogic_vector ) 
RETURN std_ulogic_vector; 


Zwischen den Typen des Packages und den herkömmlichen VHDL- 
Typen wurden folgende Konvertierungsfunktionen erforderlich: 


7 To_bit für Operanden vom Typ std_ulogic, 


I To_bitvector für Operanden vom Typ 
std_logic_vector und std_ulogic_vector, 


7 To_StdULogic für Operanden vom Typ bit, 


I To_StdLogicVector für Operanden vom Typ 
bit_vector und std_ulogic_vector, 


I To_StdULogicVector für Operanden vom Typ 
bit_vector und std_logic_vector, 


I To_X01 für Operanden vom Typ bit, bit_vector, 
std_ulogic, std_ulogic_vector, 
std_logic_vector, 
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m To_X012 für Operanden vom Typ bit, bit_vector, 
std_ulogic, std_ulogic_vector, 
std_logic_vector, 

m To_UX01 für Operanden vom Typ bit, bit_vector, 
std_ulogic, std_ulogic_vector, 
std_logic_vector. 


Weitere Funktionen des Packages prüfen auf steigende oder fallende 
Flanken eines Signals und auf den Wert 'x': 


rising_edge (SIGNAL s : std_ulogic) 
RETURN boolean; 
falling_edge (SIGNAL s : std_ulogic) 
RETURN boolean; 


: std_ulogic_vector ) Rl boolean; 
: std_logic_vector )\) RE boolean; 
Logic ) R boolean; 


Eine vollständige Beschreibung der Funktionalität aller im Package 
enthaltenen Unterprogramme würde hier zu weit führen. Dennoch soll 
anhand einiger Beispiele das Vorgehen gezeigt werden. 


Viele Funktionen werden über Tabellen realisiert, die mit dem Auf- 
zähltyp std_ulogic indiziert sind. Das Ergebnis der entsprechen- 
den Funktion wird dann nur noch durch Ansprechen eines Tabellen- 
elementes mit den beiden Operanden als Index (= Adresse) erzeugt. 


Anhand der Invertierungsfunktion und der "resolution function" soll 
dies beispielhaft gezeigt werden. Zunächst wird ein Vektor- und ein 
Matrixtyp deklariert, die mit std_ulogic indiziert sind und deshalb 
9 bzw. (9 x 9) Elemente des Typs std_ulogic enthält: 


E stdlogic_1d IS ARRAY (std_ulogic) OF std_ulogic; 


E stdlogic_table IS ARRAY (std_ulogic, std_ulogic) 
OF std_ulogic; 
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Die Auflösungsfunktion wird folgendermaßen realisiert: 


CONSTANT resolution_table : stdlogic_table 


IDEE, NT, Hr, 
EN LARRG IA, X 
Er, DT; A ehe “or, 
RI REN, ET II TER, 
ee EZ Et Eur, SHE, 
OT, rt, INT, IM, 
2, 0, Be Pe ee 2 
ON, NEE TERN, 
RI AZT, N FR IN N 


Hs NHOo%»xxcG 


FUNCTION resolved ( : std_ulogic_vector ) 
ETURN std_ulogic IS 
VARIABLE result : std_ulogic := '2'; 

-- weakest state default 


EGIN 
IE (s'Li 1) THEN 
RETURN s (s'LOW); 
ELSE 
FOR i IN s'RANGE LOOP 
result := resolution_table (result, s(i)); 


EN! 
RETURN result; 
D resolved; 


Die Auflösungsfunktion arbeitet beliebig lange Eingangsvektoren ab, 
deren Elemente die Werte der einzelnen Signaltreiber für das aufzulö- 
sende Signal darstellen. Man geht hierbei vom schwächsten Zustand 
("high impedance", 'Z', als Defaultwert des Ergebnisses) aus. Es wird 
dann sukzessive der (vorläufige) Ergebniswert mit dem nächsten Ele- 
ment des Eingangsvektors verknüpft, bis alle Elemente abgearbeitet 
sind. 
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Ein weiteres Beispiel zeigt die Realisierung der Invertierungsfunktion: 


CONSTANT not_table: stdlogic_ld : 


UNCTION "NOT" : std_ulogic ) RETURN UX01 IS 
EGIN 
RETURN (not_table(1l)); 
END "NOT"; 


Die vektoriellen Funktionen führen die Operatoren bitweise für jede 
einzelne Stelle im Vektor durch. Als Beispiel sei hier der NAND- 
Operator für zwei std_ulogic-Vektoren aufgeführt: 


FUNCTION "NAND" ( 1l,r : std_ulogic_vector ) 

RETURN std_ulogic_vector IS 

ALIAS lv : std_ulogic_vector ( 1 TO l'LENGTH ) IS 1; 

ALIAS rv : std_ulogic_vector ( 1 TO r'LENGTH ) IS r; 
VARIABLE result : std_ulogic_vector ( 1 TO l'LENGTH ); 

EGIN 
IF ( 1L'LENGTH /= r'LENGTH ) THEN 

ERT false 

REPORT "arguments of overloaded 'NAND'-operator " 


& "are not of the same length" 


EVERITY failure; 


ELSE 
FOR i IN result 'RANGE LOOP 
result (i) := not_table (and_table (1lv(i), rv(i))); 


ETURN result; 
"NAND"; 


Mit entsprechenden Tabellen werden nach dem gleichen Schema die 
zahlreichen Konvertierungsfunktionen realisiert. 
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Als Beispiel einer Funktion, die ein Boolesches Ergebnis liefert, sei 
hier die Erkennung von undefinierten Werten in einem std_ulogic 
Objekt dargestellt: 


UNCTION Is_X ( s : std_ulogic ) RETURN boolean IS 
EGIN 


Es IS 
BEN 'u' | 'x' | 'z' | 'w' | '-' => RETURN true; 
H 


EN OTHERS => NULL; 
CASE; 
URN false; 
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Die im folgenden aufgeführten Übungsaufgaben sind in zwei Kate- 
gorien eingeteilt: Übungen zu grundlegenden VHDL-Konstrukten 
und etwas komplexere, komplette Entwurfsbeispiele. Falls nicht anders 
vermerkt, sollen Signale vom Typ bit verwendet werden. 


Beispiele zur Lösung der Übungsaufgaben finden sich ausschließlich 
auf der beiliegenden Diskette. Das Verzeichnis UEBUNGEN verzweigt 
in die vier Unterverzeichnisse BASICS, BCD, ALU und TAB. Dort fin- 
den sich entsprechend bezeichnete ASCII-Files mit Lösungen zu den 
einzelnen Übungsaufgaben. 


2.1 Grundlegende VHDL-Konstrukte 
2.1.1 Typen 


m Deklarieren Sie einen Aufzähltyp namens wochentag, der die 
Werte montag, dienstag, ... sonntag annehmen 
kann. 


m Deklarieren Sie einen zusammengesetzten Typ (RECORD) 
namens datum, der folgende Elemente enthalten soll: 


O jahr (integer 0-3000) 
O monat (integer 1-12) 
O tag (integer 1-31) 
O wochentag (siehe oben) 
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2.1.2 Strukturale Modellierung 


a Beschreiben Sie einen Halbaddierer, der aus einem AND2- und 
einem XOR2-Gatter aufgebaut werden soll. 
Schreiben Sie zunächst eine Entity mit den Eingangssignalen 
sum_a und sum_b sowie den Ausgangssignalen sum und 
carry. 
Erstellen Sie dazu eine strukturale Architektur. 

a Beschreiben Sie einen 1-Bit Volladdierer 
mit den Eingängen: in_l, in_2, in_carry, 
und den Ausgängen: sum, carry. 


Das strukturale Modell soll aus zwei Halbaddierern und einem 
OR2-Gatter aufgebaut werden. 
m Erstellen Sie ein strukturales Modell für einen 8-Bit Ripple- 
Carry Addierer 
mit den Eingängen: in_1(7 DOWNTO 0), 
in_2(7 DOWNTO 0), 
in_carry, 
und den Ausgängen: sum(7 DOWNTO 0), 
carry. 
Verwenden Sie die GENERATE-Anweisung und Volladdierer. 


m Konfigurieren Sie das hierarchische Modell des 8-Bit-Addierers. 
Als Basisgatter stehen folgende VHDL-Modelle zur Verfügung: 


OÖ  or2 (behavioral) 

Eingänge: a und b, Ausgang: y 
O  and2 (behavioral) 

Eingänge: a und b, Ausgang: y 


OÖ  exor (behavioral) 
Eingänge: sig_a und sig_b, Ausgang: sig_y. 
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2.1.3 


m) 


290 


Verhaltensmodellierung 


Beschreiben Sie ein symmetrisches Taktsignal clk, das eine 
Frequenz von 10 MHz besitzen soll. Verwenden Sie dazu ein Si- 
gnal vom Typ bit und alternativ ein Signal vom Typ std_ 
ulogic. 

Gegeben sei folgende Architektur eines 4:1-Multiplexers: 


ARCHITECTURE behavioral_1 OF mux IS 


BEGIN 
sig_out <= sig_a WHEN sel = "00" ELSE 
sig_b WHEN sel = "01" ELSE 
sig_c WHEN sel = "10" ELSE 


sig_d ; 


END behavioral_1 ; 


Beschreiben Sie diese Funktionalität mit anderen nebenläufigen 
oder sequentiellen Anweisungen. 


Folgende Funktion beschreibt die elementweise Multiplikation 
zweier Integer-Vektoren (eigendefinierter Typ int_vector) 
mit einer WHILE-Schleife: 


FUNCTION mult_while (a,b : int_vector (1 TO 8)) 
RETURN int_vector IS 


VARIABLE count : integer ; 
VARIABLE result : int_vector (1 TO 8) ; 
BEGIN 
eount s= DD: 
WHILE count < 8 LOOP 
count := count +1; 
result (count) := a(count) *b (count) ; 
END LOOP ; 
RETURN result ; 


END mult_while ; 
Beschreiben Sie diese Funktion alternativ mit einer FOR-Schlei- 
fe. 


Beschreiben Sie diese Funktion mit einer Endlos-Schleife und 
einer EXIT-Anweisung. 


Verändern Sie obige Funktion derart, daß sie allgemeine, gleich- 
lange Integervektoren unbestimmter Länge und unterschied- 
licher Indizierung verarbeiten kann. 
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m Gegeben seien folgende Anweisungen innerhalb einer Archi- 
tektur: 


ARCHITECTURE assignment OF example IS 
SIGNAL a,b : integer := 0; 

BEGIN 
a <= 1 AFTER 2 ms, 4 AFTER 5 ms; 
b <= 4 AFTER 3 ms, 3 AFTER 4 ms; 
p : PROCESS (a,b) 

VARIABLE c, d : integer := 

BEGIN 

ce :=a tb; 

a 2=:8.€# 22; 

END PROCESS p ; 

END assignment ; 


Welchen Werteverlauf besitzt die Variable d für diesen Fall? 
Welchen Verlauf besitzt d, falls es als Signal deklariert wird? 
Welchen Verlauf besitzt d, falls c ein Signal ist? 

Welchen Verlauf besitzt d, falls c und d Signale sind? 


l 
o 
Ss 


Welchen Verlauf besitzt d, falls c und d Signale sind und c in 
der "sensitivity-list" des Prozesses p enthalten ist? 


2.1.4 Testumgebungen 


m Schreiben Sie für obigen 1-Bit-Volladdierer eine Testumge- 
bung, die neben der Stimulierzeugung auch die Ergebnisauswer- 
tung enthält. Verwenden Sie zur Zuweisung der erforderlichen 
Stimuli (drei Signale) eine möglichst kompakte Anweisung. 


2.2 Komplexe Modelle 
2.2.1 Vierstellige Siebensegment-Anzeige 


Es soll ein VHDL-Modell für eine Schaltung bcd_4bit (Abb. D-1) 
entwickelt werden, die eine vierstellige BCD-Zahl über eine vierstellige 
Siebensegment-Anzeige ausgibt. Da nur ein BCD / Siebensegment- 
Codierer (Modul bcd_7seg) verwendet werden soll, müssen die vier, 
jeweils 4-Bit breiten Eingangssignale im Zeitmultiplex auf den Co- 
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dierer geschaltet werden. Ein Demultiplexer (Modul dx) aktiviert über 
die Signale stellel bis stelle4 immer nur eines der vier Anzei- 
geelemente. Der Multiplexer (Modul mux) und der Demultiplexer 
werden über einen zyklischen Dualzähler (Modul ctr) angesteuert. 
Die Ausgangssignale des Gesamtmodells sind die Bitsignale a bis g 
und stellel bis stelle4. Als Eingangssignale besitzt das Modell 
das Bitsignal takt und ein komplexes Signal bcd4, das die vier 
BCD-Zahlen über insgesamt 16 Bitsignale überträgt. 


aAx 


Abb. D-1: Blockschaltbild der Anzeigesteuerung bed_4bit 


m Entwickeln Sie ein VHDL-Modell für den synchronen Dualzäh- 
ler ctr, der zyklisch die Zahlen O bis 3 binär codiert über zwei 
Ausgangsports ausgibt. Der Zählerstand soll bei einer positiven 
Taktflanke erhöht werden. 


m Schreiben Sie ein VHDL-Modell für den 1-aus-4-Demultiple- 
xer. Er soll low-aktive Ausgänge besitzen, die als gemeinsame 
Kathode der Siebensegmentanzeigen dienen: eine '0' am Aus- 
gang bedeutet, daß das entsprechende Siebensegment-Modul ak- 
tiviert ist. 


m Legen Sie ein VHDL-Modell für den 4-zu-1-Multiplexer an. 
Beachten Sie, daß hier ein 4-Bit breites Signal durchgeschaltet 
wird. 


a Entwickeln Sie ein VHDL-Modell, das eine BCD-Zahl (Zahlen O 
bis 9 binär codiert) in Steuersignale für die sieben Segmente der 
BCD-Anzeige umwandelt. Eine '1' heißt, daß das zugeordnete 
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Segment leuchten soll. Falls keine gültige BCD-Zahl anliegt 
(Zahlen 10 bis 15), soll die Anzeige dunkel bleiben. 


m Schalten Sie die Module entsprechend der Abbildung in einem 
strukturalen VHDL-Modell zusammen und testen Sie die Funk- 
tion der Gesamtschaltung mit Hilfe einer Testbench. Verwenden 
Sie Assertions zur Überprüfung der Ausgangssignale. 


2.2.2 Arithmetisch-logische Einheit 


Es soll das Modell einer arithmetisch-logischen Einheit (ALU) erstellt 
werden, das einen eingeschränkten Befehlssatz bearbeiten kann. Als 
Operanden (a und b) sollen zwei Bit-Vektoren (jeweils 8 Bit) mit ei- 
nem zusätzlichen Paritätsbit angelegt werden und als Ergebnis ein 16- 
Bit breiter Vektor, ebenfalls mit Paritätsbit, erzeugt werden. Folgende 
Operatoren sind zu modellieren: 


con_ab: Zusammenfügen der beiden Operanden (a & b), 
add_ab: Addieren der beiden Operanden, 
add_of: Addieren eines Konstanten Offsets zu b, 


mlt_ab: Multiplikation beider Operanden, 

sh_1l_b: Links-Shift des Operanden b um eine Stelle, 
sh.ir.ch: Rechts-Shift des Operanden b um eine Stelle, 
sh_1l_k: Links-Shift des Vektors a & b um eine Stelle, 
sh_r_k: Rechts-Shift des Vektors a & b um eine Stelle, 


flip_b: Vertauschen der niederwertigen und höherwertigen 
vier Bits des Operanden b, 


flip_k: Vertauschen der vier niederwertigen mit den vier 
höherwertigen Bits, sowie der jeweils vier mittleren 
Bits des Vektors a & b, 


turn_b: Drehen des Operanden b (Indexinvertierung), 


turn_k: Drehen des Vektors a & b (Indexinvertierung). 
Bei Operationen mit nur einem Eingangsvektor sollen die niederwerti- 


gen Bits des Ergebnisvektors belegt werden, die höherwertigen zu Null 
gesetzt werden. 
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Erstellen eines Package 


Zunächst soll ein Package alu_pack mit entsprechendem Package 
Body verfaßt werden, das folgende Funktionen und Deklarationen ent- 
hält: 


I Deklaration eines Typs command als Aufzähltyp der oben auf- 
geführten Befehlsalternativen, 


I Deklaration eines Record-Typs parity_8, bestehend aus 8-Bit 
breitem Vektor plus Paritätsbit, 


I Deklaration eines Record-Typs parity_16, bestehend aus 16- 
Bit breitem Vektor plus Paritätsbit, 


7 Definition des konstanten Offsets als "deferred constant" (ram_ 
offset), 


I Prozedur (passiv) zur Prüfung des Paritätsbits, welche eine Feh- 
lermeldung liefert, falls eine ungerade Anzahl von Eins-Stellen 
vorliegt und das Paritätsbit = '0' ist (und umgekehrt), 


I Funktion zur Erzeugung des Paritätsbits für den Ergebnisvektor 
('1' für eine ungerade Zahl von Eins-Stellen), 


I Funktion zur Umwandlung eines 8-Bit breiten Bitvektors in eine 
Integerzahl zwischen O und 255, 


I Funktion zur Umwandlung einer Integerzahl (0 bis 65535) in 
einen 16-Bit breiten Bitvektor. 


Schnittstellenbeschreibung 
Mit obigen Deklarationen kann nun die Schnittstelle (Entity) der ALU 


beschrieben werden, die den Aufruf der passiven Prozedur zur Pari- 
tätsprüfung im Anweisungsteil enthält. 


Architekturbeschreibung 


Die Architektur soll die Abarbeitung der einzelnen Kommandos und 
die Erzeugung des Paritätsbits enthalten. Die arithmetischen Opera- 
tionen (add_ab, add_of undmlt_ab) können im Integerbereich 
mit Hilfe der Konvertierungsfunktionen durchgeführt werden. 


Erstellen einer Testbench 


In Anlehnung an die Programmierung eines Prozessors soll die 
Testbench die Kommandos (Operatoren) und Operanden aus einem 
Textfile einlesen, an die ALU weitergeben und das Ergebnis in ein 
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zweites File schreiben. Jede Zeile im Eingabefile enthält den Operator 
und die beiden Operanden, jeweils durch ein Leerzeichen getrennt. 


Für diese Vorgehensweise sind einige Erweiterungen des Package 
alu_pack erforderlich: 


I Definition des Eingabefilenamens als "deferred constant" 
(input_filename), 


I Definition des Ausgabefilenamens als "deferred constant" 
(output_filename), 


I Da man mit den Funktionen aus dem Package textio keine 
eigendefinierten Typen lesen kann, müssen die Operatoren als 
Zeichenkette abgelegt werden und innerhalb der Testbench in 
den Typ command umgewandelt werden. Dazu ist eine entspre- 
chende Funktion zu schreiben und im Package abzulegen. 


Schreiben Sie daraufhin eine Testbench (Entity und Architecture), die 
folgendes Ablaufschema durchläuft: 


® Lese eine Zeile aus dem Eingabefile, solange das Fileende nicht 
erreicht ist. 


Lese Operator und Operanden aus dieser Zeile und lege sie an 
die ALU (model under test) an. 


Warte bis ein Ergebnis geliefert wird. 
Schreibe das Ergebnis in das Ergebnisfile. 
Gehe zurück zu ®. 


e®8® ® 


Zum Testen des Modells kann das File "ALU_COMM" auf der beilie- 
genden Diskette als Eingabefile dienen. 


2.2.3 Zustandsautomat 


Als weiteres Entwurfsbeispiel soll ein endlicher Zustandsautomat 
(FSM) dienen: 


Für einen Telefonanrufbeantworter soll eine einfache Steuerung des 
Aufnahmebandes und des Ansagebandes aufgebaut werden. Dazu ist 
folgendes Blockschaltbild zu betrachten: 
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Ansage_fertig 


Timer_ende Timer Timer_start 


TAB- 
Steuerung 


Aufnahme 


Ansage_ 
abspielen 


Hörer_aufgelegt 


Anruf_ 
aufzeichnen 


Takt Reset 


Abb. D-2: Blockschaltbild des Telefonanrufbeantworters 


Schnittstellenbeschreibung 


Beschreiben Sie die Schnittstelle der Steuerung für den Telefonanruf- 
beantworter nach obigem Blockschaltbild. Insbesondere ist auch ein 
Takt- und ein Rücksetzsignal vorzusehen. 


Architekturbeschreibung 

Die Steuerung soll folgende Funktionalität besitzen: 

® Beim ersten Klingelzeichen (Anruf = '1') wird ein Timer ge- 
startet (Timer_start = '1'). 


® Wurde nach Ablauf der Wartezeit (Timer_ende = '1"') der Hö- 
rer nicht abgenommen, wird die Ansage abgespielt (Ansage_ 
abspielen = '1'). 


® Wurde nach Ablauf der Nachricht (Ansage_fertig = '1') im- 
mer noch nicht abgehoben, beginnt die Aufzeichnung des An- 


rufes (Anruf_aufzeichnen = '1'). 
® Hat der Anrufer aufgelegt (Anruf = '0'), so wird die Aufnah- 
me beendet (Anruf_aufzeichnen = '0') und auf den nächsten 


Anruf gewartet (Ruhezustand). 


® Legt der Anrufer vorzeitig auf, wird ebenfalls in den Ruhezu- 
stand zurückgekehrt. 


® Das Abnehmen des Hörers (Hörer_aufgelegt = '0') am lokalen 
Apparat hat Vorrang und führt immer in den Zustand des Ge- 
gensprechens ("Telefonieren"). 
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Diese Funktionalität kann durch einen Automatengraphen (Moore- 
Automat, Abb. D-3) mit fünf Zuständen realisiert werden. An den ein- 
zelnen Übergängen sind die Eingangssignale in der Reihenfolge 


Anruf, Hörer_aufgelegt, Timer_ende, Ansage_fertig 
angezeichnet, in den Zuständen sind die Ausgangssignale vermerkt: 
Timer_start, Ansage_abspielen, Anruf_aufzeichnen 


non 


Durch die Verwendung von sog. "don’t cares" ("-") zur Kennzeich- 
nung nicht relevanter Eingangsvariablen kann die Beschreibung eines 
solchen Automatengraphen wesentlich kürzer gestaltet werden: 


Abb. D-3: Automatengraph des Telefonanrufbeantworters 


Erstellen Sie ein Verhaltensmodell für eine entsprechende Steuerung. 
Definieren Sie sich dazu ein Signal, das einen der fünf Zustände an- 
nehmen kann. Das Rücksetzsignal soll asynchron wirken, der Zustand 
jeweils an der positiven Taktflanke wechseln. Die Ausgangssignale sol- 
len in Abhängigkeit vom Zustand zugewiesen werden. 


Testbench 


Schreiben Sie eine Testbench zur Überprüfung Ihres Modells. Simu- 
lieren Sie dabei nicht nur einen typischen Ablauf, sondern auch vor- 
zeitiges Auflegen des Anrufenden, Beginn eines Gespräches vom 
lokalen Apparat usw. 


© G. Lehmann/B. Wunder/M. Selz 297 


3  \VHDL-Gremien und 
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Auf internationaler Basis arbeiten viele Organisationen und Arbeits- 
gruppen an der Weiterentwicklung und Verbreitung der Sprache 
VHDL. Viele davon bieten Informationen für "jedermann", z.B. über 
regelmäßig erscheinende Newsletters, mailing-Listen oder ftp-Server, 
die über das internationale Rechnernetz (Internet) frei zugänglich 
sind. Einigen der Arbeitsgruppen kann man beitreten und sich aktiv 
an deren Tätigkeiten und Diskussionen beteiligen. 


Die folgenden Abschnitte sollen einen Überblick über die wichtigsten 
dieser Institutionen geben. Die Aufzählung erhebt keinen Anspruch 
auf Vollständigkeit. Es existieren neben den erwähnten Institutionen 
noch viele weitere, nationale oder lokale Benutzervereinigungen und 
spezialisierte Arbeitsgruppen. 


3.1 VHDL-News-Group 


Im internationalen News-Net wurde im Januar 1991 eine Gruppe spe- 
ziell für das Themengebiet VHDL eingerichtet. Sie trägt die Bezeich- 
nung comp.lang.vhdl und wird täglich von mehreren hundert 
VHDL-Anwendern gelesen. 


Aktuelle Themen und Probleme zur Syntax, zu Programmen und zum 
praktischen Einsatz von VHDL werden dort intensiv diskutiert und 
neueste Informationen ausgetauscht. 


Regelmäßig werden von Herrn Thomas Dettmer aktuelle Informa- 
tionen über VHDL-Literatur, Public-Domain-Software, häufige Fragen 
zu VHDL, Anschriften von VHDL-Gremien, Arbeitsgruppen sowie 
Softwareherstellern zusammengestellt und in dieser News-Group ver- 
öffentlicht. 
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3.2 VHDL International 


Unter den Arbeitsgruppen, die sich international mit dem Thema 
VHDL beschäftigen, sind die meisten in den Vereinigten Staaten be- 
heimatet. Dort ist, neben den verschiedenen Komitees vom IEEE, in 
erster Linie die Gruppe "VHDL International, Inc." (kurz: VI) zu nen- 
nen. Hierbei handelt es sich um eine gemeinnützige Vereinigung, de- 
ren Absicht es ist, gemeinsam die Sprache VHDL als weltweiten Stan- 
dard für den Entwurf und die Beschreibung von elektronischen Sy- 
stemen voranzutreiben. Zu den Mitgliedern von VI gehören alle füh- 
renden EDA-Hersteller nebst einigen bedeutenden Elektronikkonzer- 
nen. 


Kontakt: WVHDL International, 407 Chester Street, 
Menlo Park, CA 94025, USA 
e-mail: cms@cis.stanford.edu 


Von VHDL International wird auch eine Arbeitsgruppe gesponsort, 
das "VHDL International Users Forum" (VIUF, früher VHDL Users 
Group, VUG). Das VIUF organisiert unter anderem Konferenzen und 
publiziert Newsletters. 


Kontakt: Allen M. Dewey, 
IBM Enterprise Systems, P.O. Box 950, MS P360, 
Poughkeepsie, NY 12602, USA 
e-mail: adewey@vnet.ibm.com 


3.3 VHDL Forum for CAD in Europe 


In Europa treffen sich die VHDL-Experten meist zweimal im Jahr im 
Rahmen der Konferenz EURO-DAC / EURO-VHDL und bei den Ver- 
anstaltungen des "VHDL Forum for CAD in Europe" (VFE). Während 
auf der großen Herbst-Konferenz mehr die theoretischen Vorträge im 
Vordergrund stehen, liegt der Schwerpunkt bei den VFE-Tagungen, 
die im Frühjahr stattfinden, auch auf den praktischen VHDL-Anwen- 
dungen. Beide Termine werden von Vorführungen bzw. Präsenta- 
tionen der EDA-Hersteller begleitet. Im Rahmen des "VHDL Forum 
for CAD in Europe" sind einige Arbeitsgruppen entstanden. Dazu ge- 
hört z.B. die "European VHDL synthesis working group", die sich mit 
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Problemstellungen aus dem Bereich der VHDL-Synthese auseinander- 
setzt. 


Kontakt: Andreas Hohl, 
Siemens AG, Abteilung ZFE IS EA 
Otto-Hahn-Ring 6, D-81739 München 
e-mail: ah@ztivax.siemens.com 


3.4 European CAD Standardization Initiative 


Eine weitere Organisation in Europa ist die "European CAD Stan- 
dardization Initiative" (ECSI). Ihre Aktivitäten umfassen nicht nur 
VHDL, sondern auch die Standards EDIF! und CFI2. Die noch relativ 
junge Organisation wird von deren Mitgliedern und über ein ESPRIT- 
Projekt durch Mittel der Europäischen Union getragen. 


Kontakt: ECSI Office, Parc Equation, 2 Ave de Vignate, 
38610 Gieres, France 


Zu den Aktivitäten gehört u.a. die Einrichtung sog. "Technical Cen- 
ters", die Expertenunterstützung beim Einsatz der Standards bieten, 
mailing-Listen und ftp-Server verwalten, Schulungskurse anbieten, 
Software entwickeln und vieles mehr. 


Speziell für VHDL wird von der ECSI das Informationsblatt "VHDL 
Newsletter" europaweit herausgegeben, in dem über die Arbeit der ver- 
schiedenen, internationalen Gremien berichtet wird, Zusammenfassun- 
gen von wichtigen Tagungen und Konferenzen wiedergegeben werden 
und ein Veranstaltungskalender abgedruckt ist. 


1 EDIF = Electronic Design Interchange Format 


2 CFI = CAD Framework Initiative 
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Herausgeber: Jaques Rouillard und Jean P. Mermet, 
Institut Mediterraneen de Technologie, 
Technopöle de Chäteau-Gombert 
13451 Marseille Cedex, France 


3.5 AHDL 1076.1 Working Group 


Auf dem Gebiet der analogen Elektronik, die mit zeit- und wertkon- 
tinuierlichen Signalen arbeitet, gibt es zur Zeit keine genormte Be- 
schreibungssprache. Es existiert zwar eine Vielzahl von werkzeugspe- 
zifischen Sprachen und Formaten, eine Austauschmöglichkeit, wie im 
digitalen Fall durch VHDL, ist dort jedoch in aller Regel nicht gege- 
ben. 


Die Arbeitsgruppe 1076.1 hat sich deshalb zum Ziel gesetzt, analoge 
Erweiterungen für VHDL zu entwickeln, um auch zeit- und wertkon- 
tinuierliche Signale behandeln und analoge Komponenten beschrei- 
ben zu Können. 


Es ist geplant, die Norm IEEE 1076 in einer späteren Überarbeitung 
um die angesprochenen Fähigkeiten zu erweitern. Dazu werden zu- 
nächst Anforderungen aus einem möglichst großen Publikum ge- 
sammelt, analysiert und diskutiert. Daraus entstehen konkrete Vor- 
schläge, wie eine künftige Syntax auszusehen hat. Nach deren Validie- 
rung schließt eine Abstimmung der Komiteemitglieder den komplexen 
Normierungsprozeß ab. 


Kontakt: Wojtek Sakowski, 
IMAG Institute, University of Grenoble, France, 
e-mail: sakowski@imag.fr 


Die Arbeitsgruppe unterhält auch einen ftp-Server und einen e-mail- 
Verteiler für interessierte VHDL-Anwender. 


Kontakt: e-mail: 1076-1-request@epfl.ch 
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3.6 VHDL Initiative Towards ASIC Libraries 


Über die "VHDL Initiative Towards ASIC Libraries" (VITAL) wurde 
bereits im Teil C (Abschnitt 1.5) des Buches berichtet. Der Mangel an 
verfügbaren Technologiebibliotheken auf Logikebene soll durch die 
Aktivitäten der Initiative behoben werden. 


Kontakt: Erik Huyskens, Alcatel NV, Tel. +32 3 240-7535 
e-mail: ehuy@sh.alcbel.be 


Auch von Vital wird ein e-mail-Verteiler betrieben. 


Kontakt: e-mail: vital-request@vhdl.org 


3.7 E-mail Synopsys Users Group 


Ein Beispiel für einen werkzeugspezifischen e-mail-Verteiler ist der 
sog. "ESNUG-Reflector". ESNUG steht für "E-mail Synopsys Users 
Group". Hier werden speziell Probleme und Fragestellungen beim 
Umgang mit den Synthese-Werkzeugen der Firma Synopsys® behan- 
delt. 


Kontakt: John Cooley, 
e-mail: jcooley@world.std.com 
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Dem Buch liegt eine Diskette mit Lösungsmöglichkeiten der Übungs- 
aufgaben aus Teil D, sowie den Beispielen aus den ersten drei Teilen 
(A bis C) als komplette VHDL-Modelle bei. Die Modelle sind als 
ASCI-Files mit selbstbeschreibenden Namen abgelegt und wurden mit 
einem kommerziellen VHDL-Compiler bzw. -Simulator getestet. 


Die Diskette gliedert sich in folgende Verzeichnisse: 


A BSP_A enthält die VHDL-Beispiele aus Teil A, 

A BSP_B enthält die VHDL-Beispiele aus Teil B, 

A BSP_C enthält die VHDL-Beispiele aus Teil C, 

I UEBUNGEN enthält die Lösungen zu den Übungsaufgaben aus 
TeilD. 


Dieses Verzeichnis verzweigt weiter in die Unterverzeichnisse: 


O BASICS enthält die Lösungen zu "Grundlegende 
VHDL-Konstrukte", 


O. BCD enthält die Lösungen zur Siebensegment- 
Anzeige, 

O ALU enthält die Lösungen zur arithmetisch-logi- 
schen Einheit, 

O TAB enthält die Lösungen zum Telefonanruf- 
beantworter. 


Dieses Verzeichnis enthält auch ein mögliches 
Syntheseergebnis des Verhaltensmodells als 
Gatternetzliste in VHDL und als Schematic im 
PostScript-Format. 


In einem weiteren Verzeichnis (GATE1164) befinden sich Modelle 
einschließlich Testbenches für einfache Grundgatter, welche die 9-wer- 
tige Logik aus dem Package std_logic_1164 verwenden. Diese 
können zum Aufbau eigener, strukturaler Modelle mit diesem Logik- 
system herangezogen werden. 
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Literatur 


Die im folgenden aufgeführte Literaturliste beinhaltet nicht nur die im 
Text verwendeten Zitate, sondern auch weiterführende VHDL-Bücher: 


[ARM 89] 
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[ASH 90] 


[BAK 93] 


[BER 92] 
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[BHA 92] 
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"Chip-Level Modeling with VHDL", 
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"Structured Logic Design with VHDL", 
Prentice Hall, Englewood Cliffs, 1993 


P. J. Ashenden: 
"The VHDL Cookbook", 


1990, per ftp erhältlich u.a. von folgenden Servern: 


chook.adelaide.edu.au oder 
du9ds4.fb9dv.uni-duisburg.de 


L. Baker: 
"VHDL Programming with Advanced Topics", 
John Wiley & Sons, New York, 1993 


J.-M. Berge, A. Fonkoua, S. Maginot: 
"VHDL Designer’s Reference", 
Kluwer Academic Publishers, Dordrecht, 1992 


J.-M. Berge, A. Fonkoua, S. Maginot, J. Rouillard: 
"VHDL '92", 
Kluwer Academic Publishers, Boston, 1993 


J. Bhasker: 
"A VHDL Primer", 
Prentice Hall, Englewood Cliffs, 1992 
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Sachverzeichnis 


Die im folgenden aufgelisteten Schlagwörter sind zum Teil auch 
VHDL-Schlüsselwörter, vordefinierte Attribute und gebräuchliche 
englische Begriffe. In den ersten beiden Fällen werden sie komplett 
groß geschrieben, im letzteren Fall klein. 


Abgeleitete Typen 77; 82 

Abhängigkeiten beim Compi- 
lieren 104 

ABS 128 

ACCESS 222 

ACTIVE 135; 140 

actuals 109; 178; 214 

Addierende Operatoren 125 

Addierer 257 

AFTER 139; 152; 192 

Aggregate 68; 91 

AHDL 1076.1 Working Group 
301 

Aktivierung zum letzten Delta- 
Zyklus 190 

Algorithmische Ebene 19; 37 

Algorithmische Synthese 242 

ALIAS, Aliase 87 

ALL 96; 181; 199; 205; 223 

AND 122 

ANSI 27 

Ansprechen von Objekten 89 

append 221 

ARCHITECTURE, Architektur 
29; 99 

Arithmetisch-logische Einheit 
293 
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Arithmetische Operatoren 125; 
257 

ARRAY 80 

ASCENDING 131; 133 

ASSERT, Assertions 148; 153; 
191 

Asynchrone Eingänge 266 

ATTRIBUTE, Attribute 68; 93; 
130; 205 

Aufbau einer VHDL- 
Beschreibung 29; 94 

Aufgelöste Signale 194 

Auflösungsfunktionen 193; 285 

Aufzähltypen 73 

Ausführlichkeit 52 


Barrel-Shifter 260 

BASE 131 

Bedingte Signalzuweisungen 
145 

Befehle 69 

BEHAVIOR 137 

Benutzerdefinierte Attribute 204 

Bewertung 46 

Bezeichner 60; 68 

Bibliotheken 94 

bit 74; 278 
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Bit-String-Größen 65 
bit_vector 66; 278 

BLOCK 113; 197 
Blockbezogene Attribute 137 
Blöcke 178 

boolean 74; 278 

BUFFER 99; 108 

BUS 198 


CASE 157; 254 

character 57; 74; 278 

Compilieren 104 

COMPONENT 108 

CONFIGURATION 30; 102; 
177 

CONSTANT 84 

Constraint-Strategien 270 

constraints 250; 269 


D-Flip-Flop 265 

D-Latch 263 

Dateien 72; 215 

Datenaustausch 24 

Datentypen 72 

deallocate 222 

deferred constant, deferring 85; 
103 

Deklarationen 70 

DELAYED 134 

delay_length 78 

Delta, A 186; 191 

Delta-Zyklus 186; 190 

Direkte Instantiierung 112 

Direkte Sichtbarkeit 202 

DISCONNECT 199 

Disketteninhalt 303 

Diverse Operatoren 128 
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Dokumentation 25 

DOWNTO 80; 90; 92; 116; 126; 
158 

DRIVING 137 

DRIVING_VALUE 137 


ECSI, European CAD Stan- 
dardization Initiative 300 

Einführung 15 

Einsatz der Syntheseprogramme 
248 

ELSE 156 

ELSIF 156 

endfile 217; 279 

endline 219; 280 

ENTITY 29; 97 

Entwurf elektronischer Systeme 
16 

Entwurfsablauf 40 

Entwurfsebenen 18; 37 

Entwurfssichten 16; 33 

Ereignisliste 140 

ESNUG 302 

EVENT 135; 140 

EXIT 161 

Explizite Typkennzeichnung 
213 

extended identifier 60 

Externe Unterprogramme 227 


Feldbezogene Attribute 133 
Feldtypen 79; 89 

FILE, Files 72; 215; 221 
File - VO 215 

flattening 246 
Fließkommatypen 75 
Flip-Flop 264 
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FOR 154; 160; 177 

FOREIGN 228 

formals 109; 177; 214 

Fremde Architekturen 227 

FUNCTION, Funktionen 163; 
165; 169 


Ganzzahlige Typen 74 
GENERATE 115 

GENERIC, Generics 97; 108 
GENERIC MAP 109; 112; 179 
Geschichtliche Entwicklung 26 
Globale Variablen 85 

Größen 62 

GROUP, Gruppen 207 
GUARDED 197 

Gültigkeit 201 


Halbaddierer 181 
HIGH 131; 133 


IEEE-Standard 1076 26; 54 
IEEE-Package 1164 281 
IF-ELSIF-ELSE 156; 254 
IMAGE 131 
Implizite Deklarationen 88 
IMPURE, impure functions 169 
IN 99; 108; 166; 171; 216 
indexed names 89 
INERTIAL, Inertial-Verzö- 
gerungsmodell 142 
Inkrementelles Konfigurieren 
184 
INOUT 99; 108; 171 
input 279 
INSTANCE_NAME 138 
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Instantiierung 107; 112 
integer 76; 278 


Kommentare 59 
Komplexgatter 110; 184 
Komplexität 23; 51 
Komponentendeklaration 107; 
108 
Komponenteninstantiierung 
107; 112 
Komponentenkonfiguration 
107; 179 
Konfiguration 30; 102; 176 
Konfiguration von Blöcken 178 
Konfiguration von 
Komponenten 179 
Konfiguration von strukturalen 
Modellen 177 
Konfiguration von 
Verhaltensmodellen 177 
Konfigurationsbefehle 70 
Konstanten 71; 84 
Kontrollierte Signale 198 
Kontrollierte Signalzuweisungen 
197 
Konvertierungsfunktionen 283 


LAST_ACTIVE 135 
LAST_EVENT 135 
LAST_VALUE 135 
Latch 263 

Laufzeit 144; 271 

LEFT 131; 133 

LEFTOF 131 

LENGTH 133 
Lexikalische Elemente 59 
LIBRARY 96 
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line 279 

Liste sensitiver Signale 149; 186 
Literatur 305 

locals 109; 177; 214 
Logikebene 20; 39 
Logikminimierung 246 
Logiksynthese 245 

Logische Operatoren 122 
LOOP 160; 261 

LOW 131; 133 


Mehrdimensionale Felder 81 
Methodik 40; 50 

MOD 127 

Modellierung analoger Systeme 
50; 301 
Modellierungsmöglichkeiten 48 
Modellierungsstil 250 
Motivation 23 

Multiplizierende Operatoren 
127 


Nachteile von VHDL 50 

named association 91; 110; 168; 
172; 214 

NAND 122; 283 

NAND-Gatter 251 

natural 78; 278 

Nebenläufige Anweisungen 35; 
70; 101; 145; 187 

NEW 222 

NEXT 161 

Nicht-bedingte Signalzuweisung 
145 

Nomenklatur 55 

NOR 122 

NOT 122 
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NULL 159; 199; 222 
Numerische Größen 63 


Objektdeklarationen 83 

Objekte 71 

Objektklassen 71 

ON 154 

OPEN 111; 214 

Operanden 68 

Operatoren 68; 121; 211 

Optimierung der Constraints 
269 


OR 122 

OTHERS 91; 146; 157; 181; 
199; 205 

OUT 99; 108; 171; 216 

output 279 


overloading 209 


PACKAGE, PACKAGE BODY 
30; 102; 103; 195; 278 

Passive Prozeduren 98; 174 

Passive Prozesse 98; 174 

PATH_NAME 138 

Physikalische Größen 64 

Physikalische Typen 76 

PORT, Ports 97; 108; 114 

PORT MAP 109; 112; 179; 214 

POS 131 

positional association 91; 110; 
168; 172; 214 

positive 78; 278 

POSTPONED 191 

PRED 131 

Preemption-Mechanismus 141 

Primitive 67 

Priorität der Operatoren 69; 121 
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PROCEDURE, Prozeduren 163; 
170; 192 

PROCESS, Prozesse 149; 186; 
191 

Programmunabhängigkeit 47 

Prozeß-Ausführungsphase 186 

PURE 169 


qualified expression, Quali- 
fizierte Ausdrücke 68; 213 
QUIET 135 


RANGE 74; 80; 133 

read 217; 218; 280 

readline 218; 279 

real 76; 278 

Rechenzeit 274 

RECORD 82 

Register 116 

REGISTER 198 

Register-Transfer-Ebene 19; 38 

Register-Transfer-Synthese 244 

REJECT 143 

Reject-Inertial-Verzögerungs- 
modell 142 

REM 127 

REPORT 154 

Reservierte Wörter 61 

resolution functions 193 

resolved signals 194 

resource libraries 95 

Ressourcenbedarf 274 

RETURN 166; 171 

REVERSE_RANGE 133 

RIGHT 131; 133 

RIGHTOF 131 

ROL 129 
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ROR 129 
Rotieroperatoren 128 


Schaltkreisebene 20 
Schiebeoperatoren 128 
Schleifen 160; 260 
Schnittstellenbeschreibung 29; 
97 
Selbstdokumentation 49 
SELECT 146 
selected names 92; 96; 202; 
211; 227 
sensitivity list 149; 186 
Sequentielle Anweisungen 34; 
70; 101; 152 
severity_level 74; 148; 154; 278 
SHARED 86 
Sichtbarkeit 202 
side 279 
Siebensegment-Anzeige 291 
SIGNAL, Signale 71; 86; 136; 
143; 193; 255 
Signalbezogene Attribute 134 
Signaltreiber 193 
Signalzuweisungen 139; 145; 
152; 188; 192 
Signalzuweisungsphase 187 
Signum-Operatoren 126 
SIMPLE_NAME 138 
Simulation 230 
Simulation von strukturalen 
Modellen 231 
Simulation von Verhaltens- 
modellen 230 
Simulationsablauf 186 
Simulationsphasen 234 
Simulationstechniken 232 
SLA 129 
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sliced names 90 

SLL 129 

Software 43 

Spezifikation 41 

Sprachaufbau 56 

Sprachelemente 56 

Sprachkonstrukte 67 

SRA 129 

SRL 129 

STABLE 134 

standard 97; 278 

Standardisierung 26 

std 96 

std_logic_1164 281 

std_ulogic 281 

Stimuli 235 

string 278 

STRUCTURE 137 

structuring 246 

Strukturale Modellierung 36; 
106; 289 

SUBTYPE 77 

SUCC 131 

Synopsys Users Group 302 

Syntaktische Rahmen 70 

Syntax 54 

Synthese 242 

Synthese von kombinatorischen 
Schaltungen 251 

Synthese von sequentiellen 
Schaltungen 263 

Synthese-Subsets 51 

Synthesearten 242 

Systemebene 18 

Systemsynthese 242 


T-Flip-Flop 266 
Technologiebibliotheken 240 
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Technologieunabhängigkeit 48 

technology mapping 247 

Telefonanrufbeantworter 295 

testbench, Testumgebungen 
219; 234; 291 

text 279 

Textfiles 218 

textio 97; 216; 218; 279 

THEN 156 

time 77; 278 

TO 80; 90; 91; 116; 126; 158 

TRANSACTION 135; 140 

TRANSPORT 139; 141; 152; 
192 

Transport-Verzögerungsmodell 
141 

Trenn- und 
Begrenzungszeichen 66 

Typbezogene Attribute 130 

Typdeklarationen 72; 224 

TYPE, Typen 73; 77, 288 

Typspezifische Files 217 

Typumwandlungen 68; 78 


Überladen von 
Aufzähltypwerten 213 

berladen von Operatoren 211 

berladen von 
Unterprogrammen 209 

Überladung 209 

Übungsbeispiele 288 

UNAFFECTED 147 

UNITS 76 

Unterprogramme 163 

Unterstützung des Entwurfs 
komplexer Schaltungen 49 

ntertypen 77 

NTIL 154 
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Unvollständige Typdeklara- 
tionen 224 
USE 96; 179; 203 


VAL 131 

VALUE 131 

VARIABLE, Variablen 71; 85; 
255 

Variablenzuweisungen 152; 188 

VASG 27 

Vektoren 80 

Vergleichsoperatoren 123 

Verhaltensmodellierung 33; 
119; 290 

Verifikation 230 

Verzögerungsmodelle 139 

Verzweigungen 254 

VFE, VHDL Forum for CAD in 
Europe 299 

VHDL Initiative Towards ASIC 
Libraries 302 

VHDL International 299 

VHDL-Gremien 298 

VHDL-News-Group 298 

VHDL’87 54 

VHDL’93 54 

VI 299 

Vielseitigkeit 46 

VITAL 240; 302 

Volladdierer 257 

Vorteile von VHDL 46 


WAIT 149; 154; 186 
Warteschlange 224 
WHEN 145; 161 
WHILE 160 

width 279 
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WITH 146 

work, working-library 95 
write 217; 280 

writeline 218; 279 


XNOR 122 
XOR 122 
XOR-Kette 255 


Y-Diagramm 17 


Zeichengrößen 65 
Zeichenketten 65 

Zeichensatz 57 

Zeiger 221 

Zeitverhalten 188 
Zusammengesetzte Typen 82 
Zustandsautomat 267; 270; 295 
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